Re: on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes

Alan Knowles wrote:

Some of these verge of the ridiculous, but mostly the whole thing is a bit of a wrong time/ wrong place with the introductions of namespaces imminent. Obviously prefixing is seriously affected by namespaces - asuming it goes in the core in the next few months.

Would this go for PHP5 or 6. The RFC can be changed to add that there will be a PEAR2 namespace when it is is out.

Package 2.0 from what I remember still has some flaws which make it inferior from a usability point of view to version 1.0. (I haven't converted any packages to it yet as it was just to much hastle and no clear benefits last time I looked.. over 9 month ago mind you..)

Do you remember what flaws ?

allfiles.php - looks like a kludge - It not something that looks like a consideration for a standard requirement, although if package owners want to add it they can..

Why is it a kludge ? Many people who need performance can load up all the needed files at once.

"*_once including of files not allowed" - Requires autoload() mechanisms, which are not considered by all to be the best mechanism for loading files and documenting code.. - This is a significant change and would need serious backing by all members.. I think a long time ago someone proposed class_exists(.....) ? false : require_once '......'; This seems a better compromise - as it solves 2 problem with one shot. - although an import statement would be better......

The issue trying to be solved here is to be opcoce cache friendly.

The Data Files stuff seems convoluted and confusing - there needs to be a philosophy behind their usage that drives their location. Some data files would be best located as subdirectories of the package. Others would be best in a centralized location. for subdirectory style resources, loading them should be simple.. dirname(__FILE__).'/data/......'; for others a standardize method of configurating and retrieving should be considered.. PEAR2::getStaticProperty('package', 'options') is simple and easy to manipluate, and test if a configuration is available or not. (or similar...)

That would require a base class, it would only need to be included if used but it is still a base class.

Stale packages are interesting. = If code exists in CVS/SVN then there is always the possibility on building on existing, rather than creating new. Flagging as "Stale/Unmaintained" is probably a better way to go.

Unmaintained packages are already marked as such. Stale packages can be moved to a different place in the subversion repository. Arnaud.