Re: Re: revision to the standard that would make me happy

On Mon, Jul 6, 2009 at 12:40 PM, Greg Beaver<greg@chiaraquartet.net> wrote: > David Coallier wrote: <snip> > The problem as I see it is that Travis's contention is that the proposed > standard better adheres to both existing best practices and tools. > Let's take a look at existing best practices and tools for PHP: > > 1) the PEAR Installer is distributed with PHP > 2) PEAR, Zend Framework, Solar, Horde, PHPUnit, and several others I'm > probably forgetting all use the existing PEAR_Class_Naming standard > 3) tools relating to classes: PEAR Installer, PHPUnit, PHPCS, > phpDocumentor, Doxygen, Phing > > Doxygen, as a tool not written in and for PHP, is an anomaly.  Of this > list, only Phing is not indirectly associated with PEAR or its naming > standards and all but Phing use PEAR's existing naming standards and > some variant of its best practices. > > What he (and apparently several of the current PEAR Group members) are > tacitly doing is saying that these are not in fact best practices by > supporting a naming standard that radically diverges from the current > "namespace" standard: using _ as a namespace separator and > This_Style_Naming. No, you're missing the point entirely. This_Style_Naming was done originally to emulate the idea of namespaces and packages. The initial prefix was considered the "vendor namespace", and anything below it a component or package (and below the second level, a subcomponent or subpackage). Now that you and others have provided true namespaces within PHP, we no longer need to emulate it. In fact, we shouldn't -- we should use namespaces *effectively*. This means that we need to break BC. > In fact, the standard Travis is proposing is almost identical to > Python's standard, but the Python namespace implementation is > different from PHP's, and the differences are significant - much of > the standard is actually designed around these differences (such as > lower-casing namespace names - Python uses the equivalent of :: for > both namespace separator and class method, so case is used to > differentiate between namespaces and classes). The discussions around lowercased namespaces circled around 3 arguments: 1) it's easier to normalize when you're going all to upper- or lowercase (and lower is simply more aesthetic) 2) lowercasing *visually* separates the namespace from the class name: foo\bar\baz\bat\Foo vs. Foo\Bar\Baz\Bat\Foo Yes, you can simply reverse scan from the end of the namespace, but it's really, really easy to simply look for the uppercase letters. 3) it acts as a visual cue that the code is written to target 5.3 and above. This will help particularly in the initial years of PHP 5.3 adoption, as developers will be able to easily determine which files need to be refactored just by looking at class names. Finally, the recommendation is that once in the package/component, you have the option of simply using This_Style_Naming as usual: namespace foo\bar; class This_Style_Naming // found in foo/bar/This/Style/Naming.php { } "Radically" divergent? Possibly, not necessarily. The only real question we need to ask here is: do the proposed standards make effective use of namespaces? I think the answer to that is "yes." > Having both helped to actually design the namespace implementation for > PHP, as well as having actually used the thing in a project with well > over 11,000 lines of code, I can confirm that there are several serious > issues with the proposed standard that are completely unnecessary that > many Travis has been aware of for well over a year, and actively chooses > to ignore because in his opinion the issues only occur when you don't > conform to "best practices" as defined by his experience, and not by the > experience of anyone using the existing PEAR standards.   In fact, I > have spent well over a month trying to resolve these differences over > the standard, and have received no public response beyond the emphatic > "Sorry, no way, and oh by the way, I don't consider the opinions of PEAR > developers to be relevant to the discussion" response from Travis that I > forwarded. Could you please delineate succinctly, with examples, the serious issues you've encountered? I've read several long monologues from you, but nothing that *succinctly* describes the issues you've encountered. Most of the discussion has been hypothetical in nature, on both sides, and I'm more interested in code samples. I'm going to ignore rants; code, not so much. <snip> > More to the point, I suggest that supporters of the new naming standard > actually try converting an existing PEAR, Solar, Zend Framework, or > PEAR2 package to the new standard, and then come back and tell me you > still like it.  For example, I'd suggest MDB2 as a great candidate to > explore the problems I've been trying so hard to bring to light. I *have* done some experiments already with ZF, and, frankly, did not encounter any difficulties. Granted, the components were not large, but the amount of effort was fairly easy and, other than re-writing exceptions to utilize SPL when it made sense, could likely have been scripted. -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/