The check itself is done at compile time, so the CPU loss only
happens if you don't use an opcode cache, which means you probably
don't care much about the performance anyway :).
I definitely think we should keep the warning, but as you can tell
from my commit I do agree it should be reduced to E_STRICT.
On 20-Oct-06, at 8:27 AM, Wez Furlong wrote:
I agree. Aside from making things difficult, these extra checks are
using up CPU cycles when we don't otherwise care about the "problems"
that are being highlighted.
I've been out of the loop for a couple of months, so I'm really
surprised that we've gotten all the way into late RC with such a
drastic change.
+1 for reducing the severity of these things.
+0 for taking the checks out.
--Wez.
On 10/19/06, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Hi,
I just want to say once again that all hell is going to break
loose once
we release 5.2.0 as stable thanks to the various fatal errors we are
adding for perfectly working code that breaks OO theory.
I am talking about this change:
http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&w=2
As well as the rewriting signatures when inheriting and whatever
other
fatal errors we are adding to things that are not actually fatal.
Please
for the love of PHP, make these E_STRICT or E_NOTICE. Otherwise we
will
have an army of angry users that will dwarf the one we were facing
with
PHP 4.4.
Now is the time to fix this before RC6.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
