RE: [PEAR-DEV] On PEAR quality issues and natural selection

>I have to say I like this idea. It is, of course, a complete >re-purposing of the PEAR ideal. But it would open up both the >competitive fronts while at the same time retaining quality standards >(coding standards, documentation, etc). After listening in on PEAR-DEV for the past few months I agree entirely, I feel that PEAR has entirely too much beauracracy. A great deal of it is counter-productive, IMO. This thread http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 conveys everything I've been thinking about PEAR. I don't understand the necessity to have to "INSTALL" a package, a package should be installable from just downloading the package and placing it in a directory. How many people actually have command line access? I don't, my ISP doesn't allow it. Then, whenever I want to use a PEAR package on my live server I have to manually alter each file. Packages should be completely portable, independent of the PEAR infastructure. Though after actually figuring how to use the PEAR infastructure, I thought it was quite handy, but its still useless to me since I can only use it on the development side. (If there are better methods, they aren't documented) And I don't understand the point of the centralized error handling packages. I feel this further obfuscates things. I'd rather each package address its own error handling, and use PEAR error packages if the designer feels the need to. The documentation on PEAR itself is difficult to navigate and confusing. The documentation assumes too much knowledge of the reader, even of an experienced developer. In addition to the points raised in these articles about competitive packages, I think, IMO, this is what's holding PEAR back from true greatness. Survival of the fittest, IMO, variations of the same ideal aren't always a bad thing. And in the end, let the public decide anyway! Documentation on documentation is another lacking area of PEAR, there's a link to the docbook website, but no explaination of how to write the bloody documentation, nor of how to access CVS and place it in CVS. You can get a CVS account, but no explaination of how to use it. No examples of well formed docbook xml, PHPDcoumentor is good, but its not PHPDocumentors job to explain how to add code snippets and tables and all that. Some policing, code structure guidelines and whatnot are necessary, but all the beauracracy isn't. High quality code, certainly, but all the childish regulations and whining has got to go. I also feel the code structuring guidelines should be expanded to include the one true brace convention, on all control structures, not just functions... this other convention is difficult to read and most professionals don't use it (at least none that I've encountered). Those are my gripes and $0.02. Though I don't expect anything to change anytime soon. Regards, Richard York ::::::::::::::::::::::::::::::::::::::: Smiling Souls http://www.smilingsouls.net :::::::::::::::::::::::::::::::::::::::