Yes, I know. But altered modules won't be able to use older versions of
PHP readily, and that's going to be a real problem in PECL - especially if
this goes into 5_2 branch.
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.
Personally, I'm not going to actually use the GINIT/GSHUTDOWN methods in
extensions like runkit (probably ever) as they're enough of a problem
maintaining PHP 4.0 compatability as it is. For exts that already require
5.0+, I probably will fold in the use of these after 6.0's release (at which
point 5.2 will be established and in {relatively} wide use).
Allowing the engine to exprt this functionality doesn't automatically break
anything, but when modules *do* switch to the new API, having support for it
going back to 5.2 will be *better* than only having the support go back to
6.0.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
