Re: PEAR2 Coding Standards RFC

Looking alot better ;) The only bit that stuck out was the "What beta status means" - full test suite with X% coverage.. - while this is a " would be nice ", I think you may have removed 80% of existing pear packages by this.. - perhaps something more simple like, a minimal of example / test code in docs folder. Test suites prefered... - API approval by the borg ;) * This is probably more suited to larger commonly used packages.. - the smaller ones should have the API approved before they are voted in on Pepr (although that has been missed a couple of times) I tend to agree with the competing packages rule now.. - I think filtering proposals through pepr will result in better results with competing packages... - Although I don't think we are going to ever solve the abandonware issue that some existing packages have already become.. Sometimes I wonder if trying to make a 20 collectives out of ~30 active developers is really a feasible vision... as I said before, I'd like to be proved wrong on that one though.... Regards Alan Gregory Beaver wrote:

Hi all, I have made the requested changes to the PEAR2 Coding Standards RFC at http://wiki.pear.php.net/index.php/PEAR2_Standards. * controversial items split out * adjustments based on mailing list conversations I have moved controversial things to http://wiki.pear.php.net/index.php/Controversial_Changes Also, I eliminated allfiles.php. Instead, PEAR2/Autoload.php can be used to set up include_path if necessary, and declare __autoload() if necessary, and takes care of all problems 1) beginners need only include '/full/path/to/PEAR2/Autoload.php'; and then start using classes 2) if a class/file is not found, an exception is thrown that contains include_path information and exactly what went wrong, so users will be able to report the same information they do now with "fatal error: require_once blah.php not found (include_path=".:/blah")" 3) advanced users still get the benefit of performance flexibility. It should be noted that early assertions by Alan about the lack of performance benefit from removing require_once have been disputed by Gopal, who has found up to 10% performance improvement in his work at Yahoo!. The performance benefit of removing require_once for advanced users can be significant. Most users, however, will not see more than 2% improvement. Please review the docs, find any minor mistakes, browse the proposal, and let us know what you think Greg