PEAR2 Coding standards, Autoloading and Namespaces

Hi, I like the new PEAR2 coding standards as they deal with including and autoloading. I have bit of a question on the PEAR2 standard as it might interact with the upcoming 5.3 namespaces. The documentation mentions using a segmented namespace (not sure what the best terminology is for these yet, nested seems a bad description.) The given example is PEAR2::HTTP::Request class. "PEAR2::HTTP" is the namespace. Take a more complicated package, MDB2 for example. I presume there would be a benefit to having a PEAR2::MDB2 namespace, rather than putting all of MDB2 into the PEAR2 namespace? Many packages seem to have namesake classes that share the same name as the package. For example, the MDB2 class is namesake class for the MDB2 package. Now, I presume that it would be most beneficial for the namesake class to be inside the namespace of the package that it belongs to. If it weren't, it would have to reference other classes inside its package with fully qualified namespace names. If it weren't in the namespace, it might confuse any future reflection/introspection based tools. Additionally, if it weren't in the namespace, it would probably confuse any future support for namespaces in PHP documenter. I presume that the autoloading for namespaces would simply replace :: with DIRECTORY_SEPARATOR. The negative consequence of moving namesake classes into their namespaces that it introduces a stutter into the the fully qualified name of the class in order to follow autoloading rules. The FQN of the MDB2 namesake class would have to be PEAR2::MDB2::MDB2. The file location would also have to change relative to the current convention. Right now MDB2 is located at php_dir/MDB2.php. Given a MDB2 namespace in the PEAR2 world, it would seem that it should be located at php_dir/PEAR2/MDB2/MDB2.php? I think there are some positive consequences for the file being located inside the namespace directory, for example easier file system browsing and easier VCS manipulation of the package as a unit. Should the PEAR2 coding standard have some guidance on the location of namesake classes? Now, revisiting the PEAR2::HTTP::Request example, I also wonder if there should be some guidance on the relationship between package names and namespaces. In the example as stated now, the package name is HTTP_Request, the namespace "PEAR2::HTTP" and the class name is "Request." Should the recommended location of PEAR2::HTTP::Request somehow align the namespaces with package names? For example: namespace PEAR2::HTTP_Request; class Request {} or namespace PEAR2::HTTP::Request; class Request {} It seems to me like either of these would be more future proof in case additional supporting classes were added later. The supporting classes could go in the package's namespace. One advantage to the PEAR2::HTTP_Request style namespace is that the fully qualified class name might also be reasonably mapped to a channel/package name for retrieval or documentation, or error messages. I can't say that a FQ class name like "PEAR2::HTTP_Request::Request" excites me, but on the other hand, "PEAR2::HTTP" seems a dubious namespace to me. Should there be some guidance in the coding standards for mapping package names to namespaces or vise versa? I'd like to hear people's thoughts on these issues. Apologies if this has been discussed before or this is the wrong venue. Best Regards, Jeff