suggestion: core library / application distinction
| From: | Hans Lellelid | Date: | Fri, 14 Nov 2003 15:56:04 +0000 |
| Subject: | suggestion: core library / application distinction | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-23615@lists.php.net to get a copy of this message | ||
Hi -
I've been passively following the PEAR/PEAR2 discussion/debate/battle. If there is going to be some new PEAR -- whether a PEAR2 or simply a cleanup of PEAR1 -- I wanted to make a suggestion that I think might make PEAR a more attractive option when it comes to choosing building blocks for a PHP application.
Among the people I've talked to, there seems to be a consensus that PEAR is an all-or-nothing application development environment. Inter-dependence of components and dependence on things like PEAR_Error and the PEAR base class makes PEAR components not only idiosyncratic but also bloated and generally unattractive when writing big applications (which are already in need of being performance conscious without introducing the PEAR "all"). Of course, Horde is an example of a framework that has accepted the "all" aspect of PEAR development, and I'd say that it has done quite well (it's not fast, but IMHO it's probably the best and most "PHP" architecture out there). Anyway, because of the error handling and general bloat, I find myself using PEAR components that don't depend on (e.g.) PEAR_Error like Log or Date or even HTML_TreeMenu.
Fact is that there's some awesome code in PEAR, but there's nothing really coherent to the mission or CVS tree of PEAR. As close as I can tell, it's a mixture of components and applications that are inter-dependent and share a clunky solution to PHP's hitherto lack of error handling and a frightening [but admittedly collision-free] naming convention (PHPUnit_Framework_TestCase or HTML_Template_PHPTAL -- yuk !!!).
I hope that PHP5 will fix some of this; I don't see a need for PEAR_Error with the Exception class. Indeed I hope that components in the "framework" can be made more autonomous so as not to require any PEAR.php at all. More generally, though, I think that it would be worthwhile to make a distinction between PEAR "applications" (like phpDocumentor, PHPTAL, MDB::Schema) and PEAR core components like Log/Date/Config, etc. In fact, I think it would be worthwhile to devote the "idea of PEAR" (PER?) to these core classes rather than to applications. It is these core components that IMO are missing from PHP and it would be so nice to have a universal set of lightweight flexible tools to provide Logging, Date support, Configuration/Properties, FileStreams, etc. --- similar to foundation classes in Java. Many applications out there (particularly ports of Java apps) end up re-writing the same foundation classes again & again because the needed functionality isn't being provided by PEAR.
I think that PEAR has some great applications (phpDocumentor, PHPTAL, MDB, etc.), and I think that PEAR should continue to provide a place (hosting, cvs, etc.) for such projects, but I think it would also be wonderful to have a committment to providing a set of lightweight (no PEAR_Error, among other things) foundation classes that could be used by any application. Using PEAR foundation classes for PHP applications should become the assumed means of development.
Hmmm ... anyway, my .02. I'm excited to see the future of PEAR (especially w/ PHP5).
Cheers,
Hans
Attachment: [application/x-pkcs7-signature] S/MIME Cryptographic Signature smime.p7s
Attachment: [application/x-pkcs7-signature] S/MIME Cryptographic Signature smime.p7s