Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84807
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuSVxX3oneAQx2QS_970y9SizvfdJytS8MBykyvCCs96GA@mail.gmail.com>
References: <CAF+90c-YX6tN63JwwWzn-WH2og2uffjR2YrL_JXsYKSjrQFS1Q@mail.gmail.com>
	<alpine.DEB.2.11.1502250923320.5941@whisky.home.derickrethans.nl>
	<CAMUwpuSVxX3oneAQx2QS_970y9SizvfdJytS8MBykyvCCs96GA@mail.gmail.com>
Date: Sun, 15 Mar 2015 09:34:54 +0100
Message-ID: <CAF+90c9Myq+130bhmqZ6LZm7AMuFxR-LnzewBvfCYat89NRN9w@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043be0a498dba005114f9bb9
Subject: Re: [PHP-DEV] Reclassify E_STRICT notices
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d043be0a498dba005114f9bb9
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 2, 2015 at 7:13 PM, Julien Pauli <jpauli@php.net> wrote:

> On Wed, Feb 25, 2015 at 10:32 AM, Derick Rethans <derick@php.net> wrote:
>
>> On Sun, 22 Feb 2015, Nikita Popov wrote:
>>
>> > I would like to propose reclassifying our few existing E_STRICT
>> > notices and removing this error category:
>> >
>> >     https://wiki.php.net/rfc/reclassify_e_strict
>> >
>> > As we don't really have good guidelines on when which type of error
>> > should be thrown, I'm mainly going by what category other similar
>> > errors use. I'm open to suggestions, but hope this will not
>> > deteriorate into total bikeshed.
>>
>> Those guidelines where part of the original proposal though:
>> http://grokbase.com/t/php/php-internals/06aq0a1vzx/rfc-e-deprecated
>> Which interestingly mentions your "Abstract static methods" case.
>>
>> And I did write something up (with my opinions of it):
>> http://derickrethans.nl/erecoverableerror.html
>>
>> In any case, some comments on a few of the cases:
>>
>> "Redefining" a constructor
>> - I think that should be retained (or an E_NOTICE) as it's something
>>   that might catch people out. I think it helps enough to warrant it.
>>
>> "Same (compatible) property in two used traits"
>> - I think that should be changed to an E_NOTICE, or not at all, if it's
>>   already an E_NOTICE. For a similar reason as above.
>>
>> "Accessing static property non-statically"
>> - I think this should stay E_STRICT, as it falls in the original
>>   proposal's category of "any rule that reflects common strict
>>   standards, like OOP theory that is considered harmless if not
>>   followed"
>>
>>
> I'm not against removing E_STRICT and reclassifying the errors, however,
> like Derick , I'd like to keep the trait and redefining constructor ones as
> they may really help to spot problems.
>

The redefining constructor notice is already gone with the ctors RFC, so I
won't comment on that. Regarding the trait warning: There is a tradeoff
between a) this notice can spot problems and b) this notice completely
disallows using this feature in professional code. I don't think having the
same property in two traits is in any way fundamentally wrong if the
declarations are compatible, so I don't see why we should (effectively)
completely forbid it.

Nikita

--f46d043be0a498dba005114f9bb9--