Re: Re: revision to the standard that would make me happy

On Jul 6, 2009, at 10:50 PM, Brett Bieber wrote:

On Mon, Jul 6, 2009 at 3:21 PM, Matthew Weier O'Phinney<mweierophinney@gmail.com> wrote: <snip>

Could you please delineate succinctly, with examples, the serious issues you've encountered? I've read several long monologues from you, but nothing that *succinctly* describes the issues you've encountered. Most of the discussion has been hypothetical in nature, on both sides, and I'm more interested in code samples. I'm going to ignore rants; code, not so much.

I believe the argument we're facing with the namespace and package naming requirement are pretty well described in Greg's original email. http://news.php.net/php.standards/67

I have a response to that that apparently did not make it to the standards@ list and was not quoted when this thread was brought over to pear-dev@ that proposes a solution to the problem that doesn't require a change to the spec. Sorry that wasn't more widely available. The problem is this: The package \foo\bar is created, and there's a bunch of drivers. For whatever reason (and as I pointed out, this should be caught before the package reaches API stability, but...) they decide they need to spin off the drivers into sub-packages after they've made a stable release. Under the current proposal: \foo\bar\drivers\SomeClass Becomes: \foo\bar_drivers\SomeClass Obviously, any code that has a concrete class dependency[1] is going to have an issue with this when they go to upgrade. Greg's solution is to add an extra "or" statement to standard so that PEAR can continue to maintain BC the way it does using its existing naming schema without any modifications. My solution is to handle that at the code level instead of the standards level. With that you end up with the following classes: namespace \foo\bar_drivers; class SomeClass {

    ... implementation ...

} namespace \foo\bar\drivers; class SomeClass extends \foo\bar_drivers\SomeClass { } This serves multiple purposes: * Keeps the standard as lean as possible. We want developers to be able to easily grok it, the more conditional statements we add to it, the more complex it becomes. * Moves the dependency of BC back entirely to the developer's shoulders, where it belongs. * Provides developers a simple place to include deprecated messages. To respond to this:

The question is, how can you break it up into smaller subpackages, maintain BC for everyone that upgrades, without adding a stupid stub class (performance hit)?

Stub classes, functions, etc., are used throughout programming languages to maintain backwards compatibility. They're a programmer's way of saying "oops". The larger question is why didn't the group/collective as a whole recommend the split prior to reaching API stability. The new pear2 idea of collectives and fluid designs until you reach beta allows for this. Personally, I find it much more dangerous to leave a class hanging around in its old location after it is split off into a sub-package than I do moving it and adding a stub. What happens when I unpack a tarball or do an SVN checkout that doesn't include all of the sub-packages? The stub would always (at least until the deprecated code was removed entirely) be distributed with the original package, providing a clue that there was a sub-package in the absence of an installer or package.xml file. As for a performance hit, if your mandate is the most speed you can eke out of the system and one extra class __ extends __ statement concerns you, you're using the wrong language. C, C++, or even Java, etc., come to mind as the place where you should really be doing your coding so you have complete control over system resources. As I stated before, and what was taken out of context to kick off the thread on pear-dev, this is a request for an exception that's been made explicitly for the purposes of not changing the way pear-dev has always done it. There are technical solutions to the problem other than making exceptions for single projects. The precedent an exception would set is very harmful to the future of any easily understandable standards document. -T [1]: http://docs.codehaus.org/display/PICO/Concrete+Class+Dependency