Re: Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [metabase-dev] RE: [PEAR-DEV] New Metabase Aniversary release

Let's remove some of the CC's at the top of this message ;) pear-dev binarycloud-dev metabase-dev are now the only CC's :) > Hi, > > * Alex Black wrote: > > precisely because much of the point of pear is to promote compatibility. > > again, because a database abstraction layer is a foundation component of any > > Template classes are also foundation components of modern > applications. > Too respond to both of these things, neither database abstraction layers or templating classes are core components to *any* application. They are core components to applications that need them, but in most cases neither database abstraction nor templating is really that necessary. Yeah, yeah, I know, some whiney troll will probably say "buhh, buuhh, butttttttttttttt, how else do I make my applications alll portable betweeeennnnnn differeeererent datatabases, db abstraction allows you me to do this!" Answer: It doesn't SQL & Db abstraction allow you to do this (and I don't want to even hear about metabase's XML abstraction :). Besides in any *real* application you: a) Don't really need to port it to another database that often b) Don't want to port it by using an abstraction layer, you'll want to design and optimize your tables differently on Oracle then you will on MySQL. DB abstraction and SQL abstraction do have there uses, no doubt (for example, applications that you give to other people), but they are certainly not "core components to any application." I could rant similairly on templates, but only if someone asks :) > > application, using APIs that are slightly different is a bad thing. > > Of course, but no one forces you to do that. I, as a developer, > can choose if I want to use PEAR::Metabase in my application > or PEAR::DB. > > Remember, PEAR ist not Midgard. PEAR is no application framework. > It's a pool of classes that follow coding standards. > Its more than that, its a unified/organized set of classes that follow coding standards. > > One database abstraction layer is all that is necessary. > > I definitively *DO NOT* agree with that. > I do agree. I'm not saying "down with metabase", i doubt that manuel will be folding phpclasses.upperdesign.com anytime soon, and saying "PEAR is soooo great, ohhh my fucking god!" I think we should leave PEAR::DB as the only database backend, with a unified API (perhaps extended now with the inclusion of metabase). And then let users go to phpclasses if they want metabase, its not like its really that hard. -Sterling > -- > PHP-Schulungen in Frankfurt und München! > > Mehr Informationen? >>> mailto:bjoern@thinkphp.de > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >