Re: PEAR2 package naming standards (namespace usage)

Howdy all, Greg; On Aug 31, 2008, at 10:37 PM, Gregory Beaver wrote:

Might I ask what problems have we encountered in PEAR1's naming scheme that warrant this?

This is warranted by the lack of adoption by anyone outside PEAR and in some cases open hostility toward the PEAR naming schema by those same people. Zend Framework and SolarPHP are the only two packages outside of PEAR that I know that use the PEAR naming schema. I have recommended the idea in companies where I have worked with developers that don't have a PHP background and have met with resistance. "It's too verbose," "It's too hard to explain to new developers," "It's overly complex when simple directories work," etc. There is a complete inversion of the English language in order to provide some resemblance to namespaces. Couple that with the overly verbose names with no real sense of what goes where by the neophyte programmer and you have a "standard" that will see limited adoption. The original PEAR2 naming RFC continues that by doing a s/_/::/g throughout the code and calling it a day. To anyone without a PHP background, our package/class naming system in PEAR is a barrier. Couple that with the fact that they can't be tracked directly in any VCS (be it Subversion, Git, etc.) because multiple packages have files in the same directory and we believe there is ample reason to refactor our existing naming schema to something more akin to what you find in the examples of other mature languages. The new schema provides a simplified naming standard: <vender>::<package>[::<package-level-namespaces>]::<Class> In our case: <vendor> == pear2 <package> == name of package <package-level-namespaces> == any additional hierarchy that a package wishes to use (optional) <Class> == definitive name of the class in question without meta data about where it belongs including the optional s/_/\//g replacement within the class name to allow PEAR1 style naming for directory substitutions if someone so chooses to use them instead of declaring new namespaces The <Class> PEAR1 style substitution was added by a specific request I fielded with talking to other developers about this RFC. Though I have not verified it, looking back at it now I believe it may have been born out of a misunderstanding of PHP's "namespace" support and a belief that you could do "import pear2::foo::*" and get all classes imported into your current namespace. I would be perfectly fine with removing that additional caveat from <Class> and requiring sub-namespaces if the developer wanted to segregate code into different directories. This naming schema provides a simple blueprint that can be adopted by anyone wishing to package their PHP code without having to invent some sorta of pseudo-categorization schema like PEAR1 while also addressing the concerns of those of us who use tools like Subversion and Git - including their svn:externals and git:submodules features - on a daily basis in their job.

If a package is re-factored in order to split off classes into subpackages, this would in fact break BC with the new RFC and is therefore forbidden. Why? Let's say a user is extending a driver, which used to be in:

Your example is 100% correct, and 100% irrelevant. When BC is a concern it is common - almost expected - that placeholder classes and methods are created to act as a Façade to maintain BC. I can't count the number of methods I've add the following docblock to: /** * Alias of {@link Foo::bar()} * @deprecated */ Assuming my package has logging available to it, it'll also have some sort of log call flagging the calls to a deprecated function with a trace so it creates a map for removing old when that time comes. The code sticks around through the rest of that major version, maybe two if we're being really generous, then is yanked in favor of the new, better way that has been developed. -T