On 24.08.2009, at 23:59, Rasmus Lerdorf wrote:
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.
right .. what i was trying to say was that i can see value in being
able to hide E_DEPRECATED and E_STRICT, but the error stuff shouldnt
be hidden that way. users should either display or log their E_NOTICES
and fix them!
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
