Re: revision to the standard that would make me happy

Nate Abele wrote: > On Jun 30, 2009, at 11:19 AM, Greg Beaver wrote: > >> The current standard draft says: >> >> [snip] >> >> A package may also declare sub-packages. Sub-packages may name classes >> with their own package name: >> >> <vendor>\<subpackage_name> >> >> or with the parent package name: >> >> <vendor>\<package_name> >> >> >> With this revision, it would be possible to split up a package and >> retain the same class names for newly sub-packages. This would >> literally erase my primary objection to the standard. The only thing >> left would be determining how to handle details like underscore handling. > > Hi Greg, > > Sorry for being dense, but could you provide a couple of examples of > how this naming would play out as a counter-point (or maybe a > follow-on) to the examples in the spec? Sure. in the new namespace standard, package pear2/Blah provides these classes: pear2\blah\Blah pear2\blah\blah\Driver1 pear2\blah\blah\Driver2 later on, it becomes necessary for Driver1/Driver2 to have their own life cycles, so they are split off. Suddenly, the classes become: package pear2/Blah: pear2\blah\Blah package pear2/Blah_Driver1: pear2\blah_driver1\Driver1 package pear2/Blah_Driver2: pear2\blah_driver2\Driver2 User X who has this script: <?php class MyCustomDriver extends pear2\blah\blah\Driver1 {} ?> blithely runs "php pyrus.phar upgrade Blah" and suddenly has a parse error - unknown class "pear1\blah\blah\Driver1" With the revision I've proposed, the classes could remain named as: package pear2/Blah: pear2\blah\Blah package pear2/Blah_Driver1: pear2\blah\blah\Driver1 package pear2/Blah_Driver2: pear2\blah\driver2\Driver2 and user X will not encounter a problem, and BC is not unnecessarily broken. A new package designed from scratch may choose to start out with split up packages, in which case the original naming standard could be used. The separation of packages is still supported (each package gets its own subdirectory), and the fact that sub-packages are in the same directory as their parent package is never a problem because they were designed to be this way in the first place. The only time having 2 packages in the same directory could be an issue would be if they are completely different packages. Greg