Re: Re: PEAR2 Coding standards, Autoloading and Namespaces

Hey Christian; On Apr 12, 2008, at 2:31 AM, Christian Weiske wrote:

Jeff, Any idea?

I'd like to think outside the box, if you could tell me the solution for following problem: - Package MDB3 - Driver packages MDB3_Sqlite, MDB3_MySql etc How do you load those drivers? Currently it was as easy as checking the existence of $path/MDB2/Driver/Sqlite.php and include the file with that name. If every package uses his own namespace, how do you load such a driver? Where do you store it in the file system so that it can be easily found? Making exceptions to the packagename->namespace rule would work, but defeat the purpose of the whole idea.

I've taken this discussion off-line and started working on an RFC (actually, there will be two I think). To answer you specific question of how to handle drivers. I see the package named thus: PEAR2::MDB2_MySQLDriver::Driver. It removes the need for the MySQL and Driver to be grammatically flipped (as is currently the case) and separate drivers and their related classes are more easily distinguished as they each exist in a directory along side MDB2 instead of within. The file structure would be: some/path/PEAR2/MDB2/MDB2.php some/path/PEAR2/MDB2_MySQLDriver/Driver.php The idea is to map the package name to the namespace, and keep package names as they exist today. The autoloader will str_replace() on "::" instead of "_", however. I've also prepared a sample loader: <?php // snippet for checking for a driver... $driver_name = $this->getFullyQualifiedDriverName($driver); if (!class_exists($driver_name, true)) {

    throw new UnknownDriverException($driver);

} // etc., etc. function getFullyQualifiedDriverName($driver) {

    if (strpos('::', $driver) === false) {
        $driver = 'PEAR2::MDB2_' . $driver . 'Driver::Driver';
    }
    return $driver;

} This allows for a driver to be specified without having to exist in the current directory and addresses several concerns: * svn:externals/git submodules will be usable as each directory contains a package that can be targeted * it becomes more apparent what is the package name and what is the class name (Vendor::Package::Class) On a less important note, as mentioned, it allows packages to be named properly by shedding the inherited method where English is forsaken to achieve technical goals. It also allows us to use more generic names within a package (one of the main goals with any namespace/package schema within a language). A MySQL driver class is Driver, not Driver_MySQL. By moving description of what the class is into the package name and namespace, PEAR2 code will be able to focus exclusively on naming a class for what it does rather than shoehorning it into the proper directory. While it is still a work in progress, feel free to comment here with any thoughts you have on the current RFC: http://pear.php.net/pepr/pepr-proposal-show.php?id=549 A second RFC will propose moving to lower-case names for package names to signify what is an instantiable class and what is a namespace. -T