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

Arnaud Limbourg wrote:

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. It seems that PHP6 targeting would be a better long term aim, as the result of this RFC would come into general use, just as PHP6 is released. (well assuming it ever does ;)

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 ? All a can remember is that the history of changelog was moved around in such a way that just copy and pasting the old release details into the changelog area was not feasible.. It's been a long while since I looked at it thought..

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. If someone really needs to optimize to this level, then configuring the opcode compiler with a list of files based on logging of get_included_files would prove far more efficient here. This kind of solution is unlikely to save that much performance wise, and just get in the way of developers and deployment.

"*_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" class_exists ? require_once " should do that AFAIR, saying that, the prebuilding of included files and proper analysis is really the best solution though.

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. The assumption would be that either it was configured somewhere, or not.. if it has not been configured then it's a fatal error- application was not set up correctly. It doesn't necessarily need to be a base class, although very few packages require data packages and forcing them to use a small base class seems a far simpler compromise...

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. I'm not sure removing them from the package list is a great idea, as that should generally be the start point for locating code.. (although I've already used some packages are only Pepr as they never made it to releases).

Regards Alan

Arnaud.