Re: Re: PEAR2 Coding standards, Autoloading and Namespaces

Greg Beaver wrote:

Travis Swicegood wrote:

Howdy all; On Apr 4, 2008, at 7:28 AM, Greg Beaver wrote:

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.

At the risk of encouraging a discussion that could easily devolve into petty argument... As someone who has worked with PEAR style packages, it is not easy to separate off a PEAR package inside a repository (via an svn:externals or other means) as the code exists in two places: /path/to/HTTP/Request.php /path/to/HTTP/Request/*

This is only if you are using an *installed* version of the package. PEAR source repositories contain all code within a single directory.

The driving force behind a change such as Jeff is suggesting, as I understand it, would be to completely contain the package within the Request directory. I agree that it would be much more useful. I also agree that there is a momentary "hmm" when you come across it for the first time, but anything other than that will just as easily confuse someone coming from another language. Python followed Java's example, so this isn't just a Java views the world weirdly issue. You also have the issue of how to handle imports (or is it uses now?). With the current recommendations, you possibly run into an issue where you have to do multiple imports. <?php import HTTP import HTTP::Request

both of these, by the way, are invalid syntax even after replacing "import" with "use". PHP's namespace implementation does not allow generic import (i.e. use HTTP::*;) as importing is done at compile-time, and it isn't possible to know all possible classnames, which would slow down the implementation ridiculously (see the internals@ archive for many extensive arguments over this implementation detail). One can, however, do an alias. use HTTP as a; Then both HTTP::Request and HTTP::Request::Request could be referred to as a::Request or a::Request::Request.

I might be totally off-base, however. If PHP doesn't enforce using an import-styled statement to use namespaced code, then it's a non-issue. At any rate, being able to completely enclose a package in one directory would be extremely useful, in my opinion, from a maintenance standpoint.

PHP's namespaces are simply classnames with :: in their name. "use" is only a convenience per-file (note: *not* per-request) alias so one can type less in the file or "rename" a class to avoid naming conflicts. Note that __CLASS__ and get_class() never change the returned name. In addition, call_user_func() and friends *only* work with full name. use is a convenience for static T_STRING classnames within a file. As a side note, because PEAR2 does not contain any internal require_once/include_once statements to load code, you can actually do what you're talking about with the source repository simply by writing your own class loader code for the package, or pre-loading the code. This all assumes, of course, that the package has full directory structure in its svn repo so that loading of data files actually works. In other words, maintenance ends up a non-issue for those who are bundling PEAR2 code using svn:externals, and does not justify changing the behavior every PEAR user is accustomed to already. In addition, if you're bundling installed packages, Pyrus can be used to maintain this distribution directly without saving the registry files (i.e. it can be set to only use an xml registry or simply upgrade from the package.xml and assume things are in place there already). All of the archaic methods of maintaining bundled PEAR packages are obsoleted by Pyrus and remove the need for weird naming conventions by design :). However, I would not argue with a package that chose not to create a top-level class with the same name as the package if the naming is clever. For instance, instead of calling the package PEAR2::HTTP::Request, one could simply call it PEAR2::HTTP::Client and have PEAR2::HTTP::Client::Request and PEAR2::HTTP::Client::Response and PEAR2::HTTP::Client::Exception as the classnames. My only argument is with a ridiculous name like PEAR2::HTTP::Request::Request and the even more ridiculous PEAR2::HTTP::Request::Response (request response?!). So, with clever naming, one could actually get what you're asking for and satisfy what I am asking for. I'm not sure this kind of cleverness can be legislated as a requirement. It could certainly be a suggested practice and happen at the point where a package moves from alpha to beta status and a name is chosen. Greg The current svn setup for externals does have some issues.

You can't overlap directories with svn:externals so there are still issues. I only ran into problems with autoload which didn't matter because i put it into a subdir and its just 1 file. But using PEAR2 from svn:externals is not going to work with the current setup, you're going to need a custom autoloader. -josh