Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45363
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.219.216 cause and error)
Message-ID: <4A930D54.6050705@lerdorf.com>
Date: Mon, 24 Aug 2009 23:59:48 +0200
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Stanislav Malyshev <stas@zend.com>, jani.taskinen@iki.fi, 
 Ilia Alshanetsky <ilia@prohost.org>,
 'PHP Internals' <internals@lists.php.net>
References: <4A92D936.2010107@zend.com> <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org> <4A92DC60.2050606@zend.com> <BE47C3D9-A9FA-45CD-A004-79C8479AFDD3@prohost.org> <4A92EA60.6020605@zend.com> <D3312479-4C3C-4F95-8503-FA0633FF835E@prohost.org> <4A92F13B.9000204@zend.com> <CCC293B8-52C8-4473-8027-6F7B32DC0C3F@prohost.org> <4A92FFA8.1060401@zend.com> <4A9304FC.2000906@sci.fi> <4A930956.9070709@zend.com> <250F0E93-D6F2-490F-9129-598AC6E96500@pooteeweet.org>
In-Reply-To: <250F0E93-D6F2-490F-9129-598AC6E96500@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] error masks
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Lukas Kahwe Smith wrote:
> 
> On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
> 
>> Hi!
>>
>>> Quite boring to read this thread where two persons argue about
>>> something abstract. Stas, can you give a real life example where your
>>> patch is necessary..?
>>
>> Any code where you either use @ or error_reporting which is not -1
>> would benefit from it by not processing errors that go nowhere. I just
>> looked at Zend Framework - with is pretty clean with regard to
>> E_NOTICE/E_STRICT problems - and @ is used in dozens of classes
>> around. The speedup would be probably not very big for whole RL
>> application, but it's a 10-line patch, and little things help too.
> 
> 
> well a few of those places would probably be fixable, by providing
> functions to check beforehand if calling the final function would cause
> an error. but that if course would add more overhead, but would still be
> the "cleaner" solution.
> 
> overall i am not so convinced about the ignoring approach. as for
> E_STRICT .. that shouldnt become less of an issue now that we have
> E_DEPRECATED .. but i guess that just means that in the future people
> will complain about E_DEPRECATED ..
> 
> anyways to me both E_STRICT and E_DEPRECATED are development tools that
> can be totally ignored in production. however E_NOTICE should not occur
> in production and we shouldnt encourage people to make them disappear
> entirely.

Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying to address.  To write optimal code,
they have to be entirely clean of all messages including E_DEPRECATED
and E_STRICT.

-Rasmus