Re: On PEAR quality issues and natural selection

Richard York wrote:

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)

This is a bit offtopic, but an install manager is rather important. It handles dependencies for you, and maintains a list of versions of installed packages. As with linux distributions, one can run Linux From Scratch (and many do), but its way easier maintaining a Gentoo or a Redhat/SuSE box. BTW, nothing prevents installing Pear packages from the source .tgz.

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.

This is a shortcoming of PHP, but centralized error handling is a good thing. It makes PEAR packages behave in predictable ways. I'd hate having to guess if a method call will do one of: return non-zero on error, throw a PHP error, raise a PEAR error; everytime I called a method on a PEAR class. PHP5 will put an end to this problem, anyhow.

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.

Many many packages lack documentation at all. Lots don't provide tutorials/examples to ease the learning curve. However, the reference docs are usually at least good enough. PEAR-QA is a good opportunity to address these problems.

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!

This is the central point of the debate. Here, I think we should learn from CPAN. CPAN is a case of success, and should be regarded as a good working template for modelling PEAR. I strongly disagree from the no-compete rule. It will cause PEAR packages to rot, as is the case with the XML-RPC package, stalled for over a year -- with only minor bug corrections, and no new features.

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.

Oh, there's lots of that on the web. Google is your friend. Developers don't have to be tended to like children.

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.

Bureaucracy should work in parallel with the life of packages, not in series. That is, it should intervene negatively at a minimum, just to keep minimum PEAR requirements respected. Beyond that, it should be positive intervention -- like promoting one of the 15 DB abstraction packages as the officially sanctioned.

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).

That is *really* offtopic. Pear needs one coding standard. Whichever that is, it won't please everyone. Think positively. At least it does not require Hungarian notation.

Those are my gripes and $0.02. Though I don't expect anything to change anytime soon.

Oh, me neither. But I'm in for the ride anyway. I participate wherever I can. Hope is the last to die. Cheers, Sérgio Carvalho

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc