Re: revision to the standard that would make me happy

On 30.06.2009, at 17:33, Greg Beaver wrote:

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.

That doesn't sound like something that works with the standard autoloader we're trying to rely on. - David

Attachment: [application/pkcs7-signature] smime.p7s