Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44B82F69.8080808@php.net>
Date: Fri, 14 Jul 2006 19:57:29 -0400
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Sean Coates <sean@caedmon.net>
Cc: internals@lists.php.net
References: <0F.C0.46743.0CB15B44@pb1.pair.com> <C04E78C9-4BBE-4C82-B711-AA0A28E1D381@prohost.org> <44B7AA42.9060305@caedmon.net>
In-Reply-To: <44B7AA42.9060305@caedmon.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] E_STRICT
From: cellog@php.net (Greg Beaver)

Sean Coates wrote:
> Ilia Alshanetsky wrote:
> 
>>Why not just define your own custom error handler and have it filter out
>>the error messages that you don't want to see... To me this would seem
>>like a easier approach, i would be against adding a in-language filter
>>for this.
> 
> 
> Inability to easily determine which errors come from which version of
> PHP (in userspace, or otherwise) aside, E_STRICT can't always be handled
> at runtime.
> 
> I can't think of a situation in 5.1.x where this is the case, but in
> 5.0.x, the use of 'var' (instead of public|private|protected) caused an
> E_STRICT at compile-time: before a userspace error handler could have
> been registered.
> 
> ... admittedly, this is abnormal, but I think we should keep it in mind
> anyway.

This is not entirely accurate.  A userspace error handler can catch
E_STRICT during parsing of included files and eval().  This is how we
make install-pear-nozlib.phar work with our PHP 4/5 compatible PEAR files.

Greg