Re: Merging PHPLIB into PEAR

I see PEAR as being something more than a single application framework. People have discussed standards to make it appear more uniform which is fine. But we shouldn't go so far as to force people to work in a certain way. This doesn't mean that there can't be application frameworks in PEAR, but it does mean that we should be open to more than one of those. I see no problems with adding PHPLIB and making whatever changes to it to make it integrate better with some of the other PEAR classes. I also see no problem with adding binarycloud or Metabase or anything else that comes up that presents a different way to approach a problem. PEAR is not PHP. Some thought has gone into PHP to try to not make it into a kitchen-sink scripting language where there is a hundred different ways to do something. In my opinion PEAR should be a kitchen-sink repository. We should apply whatever structure and uniformity we can to PEAR, but not so much that we limit ourselves to one approach. -Rasmus On Fri, 19 Jan 2001, Paul Meagher wrote: > > Once you make PEAR into an application framework, you change the argument > > from "PHP is great, it comes with PEAR" to either "PHP comes with PEAR, > which > > is what we need" or "PHP has PEAR, but it doesn't do what we need, so PHP > > really isn't offering us anything". If you are so set on needing an > official > > application framework, then build paf.php.net. > > Unless I am mistaken, a large number of postings in the last few days have > stated that this statement is true for web application developers: > > "PHP has PEAR, but it doesn't do what we need, so PHP really isn't offering > us anything". > > Are we on the same page? Same planet? :-) > > Regards, > Paul > > > -- > PHP Extension and Add-on Repository (PEAR) mailing list. > Documentation can be found at http://pear.php.net/doc/pear.html > To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the > mail address you subscribed with. >