Re: Re: PEAR2 Coding standards, Autoloading and Namespaces

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/* 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 ... 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. -T