[VOTE] Reclassify E_STRICT notices View as Markdown

To ensure we have no shortage of new RFC votes...

https://wiki.php.net/rfc/reclassify_e_strict#vote

Voting is open for ten days :)

From the RFC:

"Signature mismatch during inheritance
...
Possible alternative: Convert to E_DEPRECATED, if we intend to make this
a fatal error in the future.
"

Has there been any decision made which course to follow? I ask since I
don't see voting option for it (not saying it needs one!), it just would
be nice to carve in stone what's going to be done about it.

Otherwise good cleanup RFC IMHO, +1

Thanks, I forgot to drop that before starting the vote. The note is gone
now :)

Nikita

Hi Nikic,

In PHP4 times it was in fact quite common to change inherited method
signatures to bend them to one's will and/or remove parameters and
hardcode them in the parent constructor call. We now know it is bad
practice, but I bet there's lot of code using these practices in
controlled situations.

I'm going to attempt fixing the app code (including the bundled pear
libs) and report back.

So... I've spent a few hours on the cleanup and I'm still far from
getting a green build.

As you mentioned in the RFC, turning E_STRICT into E_WARNING is going to
be a BC-break for someone, and fixing this one in particular requires
far more effort than a simple search/replace.

For some applications it means heavy refactorings to ensure that all the
inherited methods have a compatible signature. That's enforced even if
the classes were never designed nor are expected to be interchangeable
(e.g. PEAR and its packages, many of which extend PEAR itself), or if
some "shortcuts" have been made (e.g. function foo() {
parent::foo("BAR"); } ).

I agree that it's a wrong usage of inheritance and we shouldn't
encourage it, but maybe an E_NOTICE would be good enough to avoid such
design mistakes.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

Hello Pierre,

Am 16.03.2015 um 02:34 schrieb Pierre Joye:

"Some of the strict standards notices are converted to an error
category that is considered more severe. As such error handlers might
treat it more severely, resulting in BC breakage."

Does it mean that some errors may end on recoverable error? Aka, an
actual break, or simply a higher error level, a warning in the worst
case?

in the "Proposal" section the RFC states:
"The following section lists all strict standards notices currently in
use (with code sample and error message) as well as the proposed
resolution and the reasoning behind it."

And then follow the actual changes:
Indexing by a resource => E_NOTICE
Abstract static methods => Remove notice
"Redefining" a constructor => obsolete
Signature mismatch during inheritance => E_WARNING
Same (compatible) property in two used traits => Remove notice
Accessing static property non-statically => E_NOTICE
Only variables should be assigned by reference => E_NOTICE
Only variables should be passed by reference => E_NOTICE
Calling non-static methods statically => E_DEPRECATED

So the RFC should not introduce a fatal error or something not catchable
by a custom error handler.

Greets
Dennis

On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals!

To ensure we have no shortage of new RFC votes...

https://wiki.php.net/rfc/reclassify_e_strict#vote

Voting is open for ten days :)

RFC is accepted with 28 votes in favor and 4 against.

The RFC is now implemented. However while landing the patch I noticed that
I missed a number of E_STRICT notices in libraries. In particular:

• mktime() without arguments throws "You should be using the time()
  function instead"

• htmlentities() with some encodings like EUC-JP throws "Only basic
  entities substitution is supported for multi-byte encodings other than
  UTF-8; functionality is equivalent to htmlspecialchars"

• mysqli::next_result() if there is no next result throws "There is no next
  result set"

While the first one sounds like something that should be deprecated, I
couldn't say what to do with the other two.

Nikita