Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24860
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <03.A2.29121.B6E31C44@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 21 Jul 2006 22:51:52 +0200
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
References: <0F.C0.46743.0CB15B44@pb1.pair.com> <44B58A36.2010900@php.net>
In-Reply-To: <44B58A36.2010900@php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: E_STRICT
From: lsmith@php.net (Lukas Smith)

Lukas Smith wrote:
> Lukas Smith wrote:
> 
> Ok I see 2 options:
> 
> 1)
>> 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.
> 
> Pierre and Anthony seem to favor this solution.

So it sounds like Derick is in this camp too.

> 2)
>> Adding such a filter API into PHP internals however seems like a 
>> considerably effort. Therefore my proposal would be to simply add a 
>> defined "header" to all E_STRICT messages that contains the PHP 
>> version in which this E_STRICT message was added. This way PEAR could 
>> provide its developer with a simple filter method that would take an 
>> error message inside a customer error handler and determine if it 
>> should be filtered out or not.
> 
>  From IRC discussions and the PEAR ML I think Michael and Marcus favor 
> this solution. I also prefer this solution.

Any more opinions on this?
I guess there is also option 3) aka "I dont care, lets not worry about it"

regards,
Lukas