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

Hi Michel, Michel Corne wrote:

Hello Josh, Great doc, really. Here are a few comments/questions: #1. re the Directory Structure: "scripts/" is missing, is this intentional?

Nope, oversight if i'm not mistaken.

#2. "data/" is meant to be anything used by a package and nothing else, right?

That's the idea.

#3. re the Base Exception class: "... Each package must define a base class that is <packagename>_Exception ...No exception..." Well, a package may trigger no exception, right? So that would be an exception. Just trying to be funny, I guess :-)

A package will most likely use exceptions :)

#4 re Loading all files at once: "... load all classes at once for easy startup and opcode caches friendliness ... No exception..." I am not sure I agree with that. A package is typically, several files/classes. Another package may not necessarily need the main class but a "sub-class". This "sub-class" may need other "sub-classes". From both, a class usage and code maintenance perspective, I would rather have that "sub-class" include all it needs in its file. Also, some packages are pretty "heavy" and including the PEAR2/PackageName/allfiles.php just to use a subset of that package might be overkill.

The idea is for the file to be there besides the others, you can use it if you want but you don't have to.

#5.*_once including of files not allowed: "... include/require/require_once/include_once is not allowed for loading class files ... No exception..." Okay for classes. Now, a package may need to include/require data that is not in a class but in an array for example in a PHP file, e.g. as a global variable or more simply a "return" statement inside an include file. This rule does not apply to those include files, right?

This is covered by http://wiki.pear.php.net/index.php/PEAR2_Standards#Data_files

#6. re the Handling dependencies: I appreciate this is optional, it should probably be a strong recommendation. The code you propose could actually be some PEAR (?) static method to which you pass the name of the dependencies so people don't have rewrite the code every time. Makes sense?

This would mean having a base class and there are strong arguments against that.

#7. re the Data files: it's funny, I realize I wrote something very similar to the method you propose recently, but I am using: PEAR_Config::singleton()->get('data_dir'); after determining that the file is being run from within a PEAR install. Here again, there could actually be a PEAR (?) static method that does the job to determine if the file is run from within a PEAR install or a raw install (coming from an SVN checkout), for all to use assuming they have a compliant directory structure. Thoughts?

Same as above.

#8. re the General policy rules: pretty good stuff overall. We indeed metrics/criteria to determine that a documentation is acceptable, that the code coverage is acceptable, that class methods are adequately unit tested,... without pushing it too far. Not easy...

Indeed, we need those. This RFC does not go into too much details to leave flexibility :)

Hope this helps. Regards,MC ----- Original Message ---- From: Joshua Eichorn <josh@bluga.net> To: PEAR Announce <pear-dev@lists.php.net> Sent: Thursday, July 5, 2007 10:18:47 PM Subject: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes Here are the meeting minutes from the PEAR Group's June 24th meeting. Sorry about taking so long to get them posted. -josh ---- June 24th PEAR Group Meeting 7PM UTC to 8:15 UTC Meeting took place over IRC Attending Christian Weiske (cweiske) Helgi Þormar (helgi) Joshua Eichorn (jeichorn) PEAR President - Greg Beaver (cellog) Not Attending Martin Jansen (mj) Paul M Jones (pmjones) Arnaud Limbourg (arnaud) David Coallier (davidc) Pear Mission Statement PEAR's mission is to provide reusable components, lead innovation in PHP, provide best practices for PHP development and educate developers. Action Items: cweiske: handle email review and voting on mission statement Last Weeks tasks http://wiki.pear.php.net/index.php/TaskList PEAR2 Infrastructure Review Wiki + pear auth, not working right, hopefully davidc can get it solved next week SVN basics are inplace, next steps are adding an api so pearweb can manage it PEAR services will be moving to a new faster server in the next few weeks PEAR2 Decisions SVN location is going to be: http://svn.pear.php.net/PEAR2/{package_name} Action Items: cweiske: run and email vote to make sure everyone agrees Vote on RFC_Policy http://wiki.pear.php.net/index.php/RFC_Policy Action Items: cweiske: run an email vote PEAR2 Standards RFC http://wiki.pear.php.net/index.php/PEAR2_Coding_Standards 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