on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes
| From: | Michel Corne | Date: | Sat, 07 Jul 2007 18:08:39 +0000 |
| Subject: | on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-47263@lists.php.net to get a copy of this message | ||
Hello Josh,
Great doc, really. Here are a few comments/questions:
#1. re the Directory Structure: "scripts/" is missing, is this intentional?
#2. "data/" is meant to be anything used by a package and nothing else, right?
#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 :-)
#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.
#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?
#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?
#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?
#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...
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
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check
it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469