For the modules which are part of the core distribution this is a
non-issue as they're branched. For PECL modules this is the same "how
old of a PHP version am I (as the package maintainer) willing to
support?". That package maintainer can: (A) Not use the new API, (B) Wrap
up some #ifdef's, or (C) Use the new API exclusively and eschew pre-5.2.
Right, and that's why I think it's problematic to have such a major change
in the API, because (A) and (C) are the likeliest outcomes - (B) is
virtually unmanageable. Take a look at what it takes for an extension to
adapt to this, and then imagine all of it #ifdef'd....
The important part of (A) is "not yet" (which I tried to express in my
second paragraph). It's the same reason why userspace package maintainers
aren't using exceptions and other 5.x specific features en masse *yet*, and
why goto won't be used in many scripts when 6.0 is first out -- okay, not
the only reason why it won't be used :)
As for (C), I can't imagine an extension maintainer going that route unless
they have other *more compelling* reasons to give up on pre-5.2 versions.
There's just not enough of a win to merit alienating those earlier versions
*yet*. Noone's forcing module authors to break compatability with older
versions, this is just giving them the choice to do so, and get a cleaner
piece of source in the process. It's also making it so that when those
extension maintainers do reach that point, they don't have to alienate the
(presumably larger) pre-6.0 audience, they only have to do so for the
(smaller) pre-5.2 audience.
I'm sorry Steph, I know your position, but I just don't understand it. This
is a minor gain at no cost. Minor enough that it's not worth it to me to
fight with you over it, but no-cost enough to compel me to against my better
judgement... :)
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
