Hi cbichis, and thanks for your thoughtful feedback. I agree with some of what you say, but let me add my personal perspective:
1) I can see the value of this, but it also a matter of speed and flexibility. Q2A has gotten to the point where it's quite framework-like itself, but specifically optimized for its own requirements. In the short run this will no doubt scare off some developers, but perhaps in the long run it will make for a better product. I know that if I was installing a big script on my site, I wouldn't want it to be based on a standard framework - too much extra weight that I don't need.
2) In the case of Q2A my two main problems with using OOP throughout are that: (a) for compatibility with PHP 4 this means defining every method for a class in a single PHP file, which means in turn that a lot more PHP will have to be compiled for every page request, creating a performance drag, and (b) apart from some specific cases (e.g. the theme class) where we need overloading, I can't really see what OOP would do except change the syntax slightly. And doing encapsulation properly would be a nightmare in terms of the numbers of getters and setters required for something like a post or user.
3) Q2A is MVC through-and-through, but I can see that might be hard to spot, since it's not implemented using the usual object-oriented pattern.
4) The JOINs are all there to enhance performance, relative to performing multiple SQL queries one after the next. Perhaps you can post a specific example of a query you feel could be improved? (Or maybe you're talking about the big UNIONs, which are used to reduce query latency - these certainly can reduce performance if your database is running locally, but can be switched off via qa-config.php.)
Anyway, thanks again for your constructive feedback. I hope at least the above explains my thinking, even if we agree to disagree :)
