Edin Kadribasic wrote:
Edin Kadribasic wrote:
Stanislav Malyshev wrote:
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.
I think fatal error should be definitely removed or the rules be at
least relaxed sufficiently to accomodate for PHP flexibility - e.g.,
() should be allowed to be overriden with ($a, $b, $c), etc. In light
of technical difficulty to implement sufficiently flexible cheks, I
would not mind removing them altogether or demoting them to very low
priority notice.
Yes, it was my opinion as well that E_NOTICE would be the most
appropriate choice here.
Hate to have to reply to myself, but to clarify.
I believe that most OO "strictness" fatal errors should be demoted to
notices.
* Changing function signatures in derived classes
* Accessing non-existing class constant (print myclass::myconst)
* Creating class variables (myclass::$myvar = 1)
The last two exist in non-OO versions and there accessing a non-existing
constant is a E_NOTICE and you don't have to declare variables at all,
so I guess we should not take 180 degree turn in their OO equivalents.
So it seems that the question seems to be mainly about if this should be
an E_STRICT or E_NOTICE right?
Here is my current understanding of things:
E_STRICT: "improper" yet workable OO code warnings, especially for
unclean code style that will not be removed but also things that are
planned for deprecation in the next major version
E_NOTICE: "improper" yet workable procedural code warnings?
Would be nice to get this resolved before RC6 ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
