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

I missed most of this. - some of these are a bit odd..

Vote on RFC_Policy http://wiki.pear.php.net/index.php/RFC_Policy The is no 'why is this being created?' answer here.. I could not understand how this differs from the current situation, or if there where any changes what was the reasoning / rationale behind them.

Action Items: cweiske: run an email vote PEAR2 Standards RFC http://wiki.pear.php.net/index.php/PEAR2_Coding_Standards 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. 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..) 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.. "*_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 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...) 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.

Need to decide on location of php code in the SVN repo Action Items: cweiske: run an email vote Design Guide Fits into ears best practices goals, big project, maybe start something on the wiki Welcome Email New user process for pear2 would be: 1) users proposes a package 2) a mentor is assigned to the user to answer their questions and help tweak the package 3) user does a few alpha releases, then proposes moving to beta Mentor sends the welcome email Mini-FAQ will help new dev and mentor through first steps docs for package.xml, a quick how-to-use-the-roadmap-bugtracker to generate a first package.xml, locations of stuff (svn, mailing list archives etc) Action Items: cweiske: ask pear.dev what should be a on new developer faq Schedule Next Meeting Shooting for: 2007-07-08