OOP naming - proposed tweak to standard

Hi, Since no one is choosing to respond to the technical question I raised about the proposed standard, I'd like to ignore the folks who raised it for the moment and start an actual discussion on the proposed naming standard. I'll start with two separate threads, this one, and the one titled "OOP translation of _ and \ to DIRECTORY_SEPARATOR - proposed tweak to standard" Summary: ======== read the following as a regular expression where capital letter represent capitalized portions of the naming standard old: vendor\package(_anotherportion])*\Classname(_Subname|\Subname)* new: vendor\Package(_?[Aa]notherportion)*(\Classname(_?Subname|\Subname)*)? Advantages: much greater naming flexibility, better development flexibility when a package is subdivided at a later date Disadvantages: a generic error message stating the package name is not possible. Details: ======== Some vendors may not want to make a clear separation of package and class name, so that a class such as: foo\db_driver_mysqli\Mysqli under the current standard could become: foo\Db\Mysqli or foo\Db_driver\Mysqli or foo\Db\Driver\Mysqli or foo\Db\Driver_Mysqli or even foo\DbDriver\Mysqli Why allow this flexibility? Imagine that in August, the vendor foo releases a package for database introspection, and at that time, all the drivers are pretty minimal wrappers, classes of only a few lines each, so they are all bundled. We get this package/name setup with the old way: foo\db_introspect\Driver\Mysqli foo\db_introspect\Driver\Sqlite In August of the following year, a major update is made to the package, providing much better functionality, but requires each driver to become quite extensive. In addition, each driver is maintained by a separate team, and some of the more complex drivers are holding up the entire release process, stability between drivers varies, and so it becomes necessary to split up the package into separate drivers. The new names become: foo\db_introspect_driver_mysqli\Mysqli foo\db_introspect_driver_sqlite\Sqlite Now, a user who has been using one of these custom drivers in a script: <?php class mydriver extends foo\db_introspect\Mysqli {} ?> The only way around this problem is to provide a hack in the original package: <?php namespace foo\db_introspect; class Mysqli extends \foo\db_introspect_driver_mysqli\Mysqli { function __construct() { trigger_error(E_USER_WARNING, 'Warning: foo\db_introspect_driver_mysqli\Mysqli is the new class name for the mysqli driver'); call_user_func_array(array('\foo\db_introspect_driver_mysqli\Mysqli', '__construct'), func_get_args()); } } ?> This hack both slows down execution (permanently if the E_USER_WARNING is removed, as the user is unlikely to ever notice the change unless they are diligent, which end users rarely are), and is annoying. With the proposed standard, the two classes could be named: foo\Db_Introspect\Driver\Mysqli foo\Db_Introspect\Driver\Sqlite or foo\Db\Introspect\Driver\Mysqli foo\Db\Introspect\Driver\Sqlite and after the split, the class name can remain the same, because the package name changes from db_introspect to db_introspect_driver_mysqli. This kind of split is very common in longer-lived repositories, PEAR has several extremely popular packages that have gone the split-package route, and it has been very successful as a means of finer granularity when it comes to separate release cycles and separate stability markers to help users understand the true stability of a larger package with relatively self-contained components. Thanks, Greg