Re: PEAR2 package naming standards (namespace usage)

Hi, Travis Swicegood wrote:

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.

"...examples of said hostility can be found here and there". Or can't they?

Zend Framework and SolarPHP are the only two packages outside of PEAR that I know that use the PEAR naming schema.

"PEAR naming schema was so spectacularly bad that Zend adopted it". Yeah, right. Zend dumb, we smart, we drop schema.

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.

Once again I see the svn:externals handwaving here. Can you please describe a real world scenario where svn:externals will be useful for working with PEAR packages? Thanks in advance.

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.

Yeah, you are right that your proposal adds a lot of additional work for PEAR package developers. And the main problem with it is that additional work is clearly visible, while additional benefits are, shall we say, vaporous.