Re: Re: [VOTE] Intermediate Results

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