> * Manuel Lemos wrote: >> I think that the greatest point of the merger is to have one and only >> one abstraction layer in PEAR, > > I think consensus was that there shouldn't be "the one and > only XYZ" PEAR class but "more than one XYZ" PEAR class (like > IT[X] and the PEAR rewrite of PHPLib's Template class).
Again, I agree about everything but database abstraction. It's fine to have applications use 5 different template engines as its only a matter of taste. binarycloud supports smarty, xslt, and standard php classes.. I'm sure we'll support more in the future. The database abstraction layer's behavior and capabilities dictate application development and we sure as hell don't want 5 abstraction layers with the same API floating around. IMHO that's actually _worse_ than just having different abstraction layers compete, because it can confuse new developers. We had this discussion a while ago, I was actually under the impression that everyone agreed that metabase was the most architecturally and functionally mature package, while PEAR clearly had a cleaner OO api because it wasn't burdened with PHP3 compatibility. I would _very_very_very_ much like to see metabase core code replace the current PEAR::DB codebase, but use the same API as the existing PEAR::DB. PEAR people and us out there building applications have a lot to gain if that happens. _If_ that happens I think we are all better for it: we gain both the good api and the mature package... and everyone can start using the same abstraction layer so we can all start sharing applications properly (again one of the primary ideas behind binarycloud). If it is indeed the intention of those running pear to (in the long run) have multiple abstraction layers, I think that is a bad mistake. However, until whoever decides these things makes themselves clear I don't really have an opinion :) _alex -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
