* Paul Waring <[EMAIL PROTECTED]> : > On Sat, Jun 25, 2005 at 10:32:41AM -0400, Matthew Weier O'Phinney wrote: > > If somebody could offer some *constructive* criticism of PEAR -- PEAR as > > it is TODAY, not "3 years ago, when I last tried it" -- these comments > > would have more weight. As it is, I feel they're just FUD based on > > ignorance. > > The documentation for some of the less well known packages is poor or > non-existant, or at least that's what I've always noticed and has been > my major bug bear with PEAR for a long time.
Indeed, the DocBook requirement for PEAR documentation is a major issue even with PEAR developers. > For example, I want to use the DB_Pager module but there is *no* end > user documentation, all I have to work with is some poorly formatted > information pulled from the API comments. Just an FYI: Use the Pager package instead. Under doc/Pager/examples in your PEAR directory is a Pager_Wrapper.php script that shows how to use it easily with DB. Pager, unlike DB_Pager, is well documented. > There are also a lot of packages (again, less well known ones) that > haven't been updated in a long time, in some cases several years. I'm > not saying that PEAR in general is a stale project, or that it's no good > (on the contrary, I use several of the packages on my sites and they're > very useful), but I do get the feeling that the non-core packages have > been left to rot both in terms of updates and documentation. This is an issue I've seen PEAR attempt to address this past year through the introduction of its QA team. But the process is still far from tuned. The above are *great* examples of why people might not choose PEAR -- and constructive ones at that. Thanks. > I've used both PEAR and CPAN for a few years now and I've noticed that > CPAN tends to win hands down in terms of documentation and updates. That > might just be down to the particular packages I've happened to use but > given a choice I know which one I'd rather use. Ah, a fellow perl developer! CPAN is, for me, *the* reason to code in perl. The perl culture is one that includes testing and documentation as the norm -- and that has made for a solid library in CPAN. However, the TIMTOWDI principle also means that forking is a foundation principle. This can be seen as either a pro or a con: pro, in that you have choice in what module to use; con, in that you then have to evaluate a number of modules. After having said that, though, I'll continue coding PHP anyday! -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association | http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
