Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <006201c68b1a$b9338610$88051fac@OHRLVN4523SG>
To: "Steph Fox" <steph@zend.com>,
	"\"Dmitry Stogov\"" <dmitry@zend.com>
Cc: "Ilia Alshanetsky" <ilia@prohost.org>,
	"Andi Gutmans" <andi@zend.com>,
	<internals@lists.php.net>
References: <000001c68af5$50876930$6e02a8c0@thinkpad> <003f01c68b13$4f9ce680$88051fac@OHRLVN4523SG> <0fd201c68b16$2134af00$6602a8c0@foxbox>
Date: Thu, 8 Jun 2006 09:43:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] Automatic module globals management
From: pollita@php.net ("Sara Golemon")

> 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