Re: Re: PEAR2 Coding standards, Autoloading and Namespaces

Jeff Moore wrote:

The drawback to this is that the fully qualified class name for Request in this case is PEAR2::HTTP_Request::Request. More controversial would probably be the question of where the PEAR2 exception class would go? PEAR2::Exception::Exception? Hi,

I think this is going overkill. PEAR 1.x has had namespaces that are quite clearly defined by the use of an underscore. In other words, these classes are in the top-level namespace: PEAR DB MDB2 and so on These classes are in the "PEAR" namespace: PEAR_Error PEAR_PackageFileManager PEAR_Exception These classes are in the "HTTP" namespace: HTTP_Request HTTP_Common These classes are in the "PEAR_PackageFileManager" namespace: PEAR_PackageFileManager_CVS PEAR_PackageFileManager_SVN In PEAR, this means that the Request class in the HTTP namespace is named "HTTP_Request", not "HTTP_Request_Request." PEAR2 does not seek to change this logic. The PEAR2::HTTP::Request class is in the PEAR2::HTTP namespace. I understand that Java does things differently, but that is not a logical argument any more than saying "Joe Shmoe does it this way". I want us to take a look at the actual use cases that our PEAR2 packages will be used and both the migration from PEAR1 and for brand new users (I expect we will have a lot of the latter due to the ease of installation Pyrus and PEAR2 standards will provide). For instance, if I want you to pass the butter, I don't ask "Please pass the butter butter". Seriously, though, the logic it takes to think in terms of packages and the classes within a package do not apply here because java distributes packages as a language feature, and enforces class naming. This requires a level of WTF that is unnecessary for PEAR. Packages are an abstract entity that are used only when downloading. The class names are what will be used on a daily basis, and I strongly encourage us to think in those terms. Which are you more likely to find natural to use, PEAR2::HTTP::Request, or PEAR2::HTTP_Request::Request? If I saw the latter classname, I would scratch my head at the redundancy, and expect the class to be in either "PEAR2/HTTP_Request/Request.php" or "PEAR2/HTTP/Request/Request.php". Both of these are confusing at best, and obfuscate the actual location at worst. Let's not go down that path, that way darkness lies. The intention of moving to namespaces is to do this action: s/_/::/ and move on with our lives. It is also another move towards using language features in place of convention, a move we've taken before (PEAR_Error => PEAR_Exception) and provides us much better interoperability with third-party projects. The purpose of the "PEAR2" prefix is to provide a clear top-level namespace for all PEAR2 packages so that (for instance) a PEAR2-specific autoloader can be written that does not interfere with other autoloaders, and so that our classnames can't conflict with other classnames. Thanks, Greg