Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25986
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 212.112.227.169 cause and error)
Message-ID: <452757E7.3040207@php.net>
Date: Sat, 07 Oct 2006 09:31:51 +0200
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Edin Kadribasic <edink@emini.dk>
Cc: internals@lists.php.net
References: <A6.E3.49133.499A2154@pb1.pair.com>	 <50.8B.48579.ED205254@pb1.pair.com> <45252FC7.9030500@php.net> <4e89b4260610060728v51b1ba65m69304a88d693ce7d@mail.gmail.com> <45267188.9030107@emini.dk> <45267B7D.9080206@zend.com> <45267C07.3090404@emini.dk> <45267D5A.70401@emini.dk>
In-Reply-To: <45267D5A.70401@emini.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [VOTE] Intermediate Results
From: lsmith@php.net (Lukas Kahwe Smith)

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