Re: Advice from an outsider, hopefully useful

-- Greg Beaver <greg@chiaraquartet.net> wrote (on Thursday, 28 May 2009, 01:25 AM -0500): > I just read the few messages on the standards list, and would like to > make a quick suggestion. Before you all pull the trigger of that weapon > aimed at your collective feet, take a page from the W3C, and do an > extended period to request comments on the standards from the public > before announcing them as finalized. Otherwise the risk is a standard > in name only. > > Another way of thinking of it: you all are the esteemed ambassadors from > your projects, but you still have to return home and convince your > partisan bickering masses that what you have negotiated with foreign > powers is in their best interest. I'm going to point out here that the standards in question are all ones that have been under *lengthy* review by the PEAR group (I believe some of these date back as far as 2 years). Many of us in that meeting are using either PEAR standards or derivatives of PEAR standards. The meeting actually dates back to php|works last fall, when several of us started discussing those standards and how we could get closure on them so that our representative projects could move forward. From my point of view, we simply discussed some of the sticky points of the standards as written, and finally made some decisions. There's already been plenty of discussion, and at some point that discussion needs to conclude and decisions must be made. (Believe me, I'm sure we could argue these for years to come.) > About the actual proposal, For me, some more clarification/changes are > needed on a few points: > > 1) The standard only mentions Underscored_Classnames, but has no mention > of the truly standard way of doing things: Backslashed\Classnames. > ns\name\Class\Name works just fine (the namespace/class barrier is > obvious - the first capital letter is the start of the classname), and > allows access to sub-namespaces using "relative namespace paths" (see > the manual for clarification on this point, it was not present in early > alphas of PHP 5.3). We actually did discuss this. The idea is that there is a vendor namespace, and a component/package namespace. Within the latter, there may be sub-components/packages nested arbitrarily deep, and this is the recommended way forward. For BC and migration purposes, Underscored_Classnames will still be allowed beneath the vendor\package namespace, and follow the original PEAR1 standards. > 2) Why is the package name present with underscores in the namespace > name? I raised strong objections to this point over a year ago when it > was first proposed to PEAR, and these seem to have been ignored. It > will encourage coding mega-packages or weird hacks like empty shell > classes (namespace ns/package;class Classname extends > ns/split_package/Classname {}) for API BC compatibility. Far simpler, > and much better, is to require vendor\ only, and to allow > vendor-specific class name/package name mapping with a suggested format. The underscores in namespaces are primarily for readability when you have a multi-word namespace. As an example, in ZF we have the component Zend_CodeGenerator. When normalized, this becomes zend\codegenerator -- which is somewhat harder to read. Underscores make this zend\code_generator -- which offers better readability. The intention is not to allow for split packages -- it's simply for readability. > 3) Arguments or standards suggestions that were ruled out need to be > documented as well, or you'll find that newcomers talk in circles > re-hashing everything. Good point. I'll point out one of those now. Regarding the decision on naming conventions surrounding abstract classes and interfaces, a strong group of us were of the mindset that these should be named generically, without hungarian notation. However, in practice, this becomes very difficult, particularly for non-native English speakers. As an example, interface names should usually describe capabilities (Count_able_, Read_able_, etc) and are thus best written as adjectives. Many nouns, however, do not map easily to adjectives: a "Personable" does not imply an interface describing a person; "Resource" could be either an interface *or* an abstract class; etc. These nuances are even harder to understand if you do not have an excellent grasp of English -- and in many of our projects, native English speakers are actually the exception. As a result, we decided that suffixing the class with Abstract and Interface was the best path forward: PersonInterface, ResourceAbstract. While this does not satisfy the academics amongst us, it's a pragmatic resolution. > Let's also not ignore ezComponents or pecl/automap solution to locating > classes - a static array mapping class name to file. This is much more > performant in autoload (no include_path search), but requires the extra > step of generating the static array. Thus the standards should mention > that vendors may provide a vendor-specific autoload which should be > loaded before the standardized one. We're recommending a common autoloader -- but that shouldn't imply that you can't use other autoloading strategies. The main reason for suggesting a common autoloader, and particularly for having one included in the SPL, is to encourage interoperability between frameworks and libraries that follow these common standards. But, as you note, other strategies exist, and due to the nature of spl_autoload, can be used in conjunction with this solution. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/