On Tue, 2002-01-22 at 22:24, Björn Schotte wrote: > * Alex Black wrote: > > > 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. > > Yes, which is not a good idea. If you're tying to get people to use a common > > set of high quality classes, you'll need to introduce some standards. > > But furthermore you need to assure that you don't influence > people too much while promoting PEAR as the new solution on > PHP's heaven. > > > difference. I have no interest in PEAR as an application framework, I like > > it as it is: pool of classes that follow coding standards. > > Yep. > > > If PEAR will allow multiple versions of a foundation component like database > > abstraction, then PEAR certainly is CPAN, with coding standards added. > > I really don't think so. If it would be, I can't see any > disadvantages. Why should PEAR people force the developers > to use "the one and only" DB abstraction class?
Nobody is forcing anyone to do anything, but the fact is that if you want to make components that deal with databases, you need to support one or more database APIs. Most people will feel that supporting several database abstraction layers is a waste of time, so we wish to provide _one_ API that all PEAR components can leverage. If we are too chicken to make this decision, we can't make interoperable components. Now we've even decided to merge PEAR DB and Metabase, and today it seems most people are tired of having multiple database layers, and welcome this effort. I don't understand why this is an issue for you, could you explain? - Stig -- 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]
