RE: [PEAR-DEV] PEAR2 package naming standards (namespace usage)

First, a preliminary question: what's about http://wiki.pear.php.net/index.php/PEAR2_Standards ? Both RFCs seem to be contradictory. For example, take that (wise) rule taken from Arnaud and Greg's proposition: # All public classes must be in their own file with underscores (_) or namespace separators (::) replaced by directory separator, so that PEAR2_PackageName_Base class or PEAR2::PackageName::Base class is always located in PEAR2/PackageName/Base.php And now let's take Travis' proposition: # All underscores (_) in the package name (i.e., everything that's lowercase) will not be translated as anything other than underscores # Underscores within the <ClassName> portion will be treated like PEAR1 to allow for sub-directories without specifying a sub-namespace ?? Now, my comments: 1. Travis'RFC focuses on MDB2, and tries to solve a problem raised by that particular package. Other PEAR packages, even those defining subpackages, may not necessarily meet that problem. The problem is (if I understood it correctly) that we want the MDB2 subpackages (the "drivers") to have their own SVN repositories, because we don't want the user to have to download 1 Mo of drivers code, if he only needs the MySQL driver. But look at large OO applications: their namespaces can contain two, three, four depth levels, with a dozen of subpackages at each level, containing plenty of classes each, and there is only ONE global SVN repo for the whole code, one SVN repo for the whole project. There is some good sense to stick to one versioning repository for a project, especially when it is Subversion. Does Michel Gauthier really needs 3 SVN repos, one for his driver Crypt_GPG_Driver_Php, one for his driver Crypt_GPG_Driver_GnuPG, and one for the rest of the code??? This is absurd. Have a look at large open-source Java projects (Java is not PHP, nor PEAR - ok! - but it is interesting anyway, because there is a long experience with namespacing in Java, and a long experience with big projects handling as well). Sometimes, you will find one SVN channel for 90% of a project, while the remaining 10% are tracked into 1 or 2 separate SVN repos. This happens when you want to isolate a component that is marginal, or that is stand-alone, or developed by a different team, etc. But this is not that frequent, AFAIK. I repeat, MDB2 is a particular case, and it would be dangerous to focus on that package - at the risk of setting up a crooked naming standard. (There is a solution for the MDB2 problem BTW: making its drivers become full PEAR packages, like Structures_DataGrid did with its datasources, which are independant packages, or like they did in Perl, with their abstract layer package DBI. Then the MDB2 drivers would get their own SVN repos. This would mean refactoring MDB2, but it WILL be necessary to change MDB2 anyway) 2. In short, Travis, you're saying to us: "Ok, do what you want with your #^§$%*! namespaces, I don't care, but your classes must be named according to the PEAR1 style, with underscores, and the directory structure must conform to the former PEAR1 structure." Not sure we are taking benefit of the namespaces... don't you think? IMO, Arnaud and Greg's initial RFC was enough. Baptiste