Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44B54CAE.70909@zend.com>
Date: Wed, 12 Jul 2006 23:25:34 +0400
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Lukas Smith <lsmith@php.net>
CC:  internals@lists.php.net
References: <0F.C0.46743.0CB15B44@pb1.pair.com>
In-Reply-To: <0F.C0.46743.0CB15B44@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] E_STRICT
From: antony@zend.com (Antony Dovgal)

On 12.07.2006 19:56, Lukas Smith wrote:
> Hi,
> 
> PEAR is currently in the process of deciding from when on we want to 
> mandate PHP5 as the target platform. Currently it looks like sometime in 
> the next 3-6 months we will likely only accept PHP5 only packages.
> 
> We are also pondering how to best approach E_STRICT. It is not feasible 
> for us to try to provide multiple packages per major version in order to 
> keep up with new E_STRICT notices that might require features not yet 
> available in previous versions.
> 
> Obviously one solution would be to disallow making anything an E_STRICT 
> notice that is not available since the first release of the given major 
> version. However I think that would defeat the purpose of E_STRICT.
> 
> Another solution would be to provide an easy way to filter out E_STRICT 
> messages based on the version they have been introduced. This would 
> enable a package developer to say "I want to be E_STRICT compatible upto 
> PHP 5.1.4". Which would mean that he could filter out any E_STRICT 
> notices that may for example get introduced in PHP 5.2.

Lukas, I thought we already discussed and agreed that the only acceptable solution is NOT 
to add any E_STRICT messages if the recommended way didn't exist in first release of the major version.
This apparently requires versioning and its support in PEAR.
And personally I think this is the only solution we can accept.

Adding some kind of hypercomplicated API for "filtering" E_STRICT is definitely huge overkill.

-- 
Wbr, 
Antony Dovgal