On Mon, Mar 2, 2015 at 7:13 PM, Julien Pauli <jpa...@php.net> wrote: > On Wed, Feb 25, 2015 at 10:32 AM, Derick Rethans <der...@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
