[RFC] E_STRICT

Marcus Boerger wrote:

Hello internals,

right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so) wants the change only on a major version change like 5.0 to 6.0.

Currently the manual says:
<manual>
2048 E_STRICT (integer) Run-time notices. Enable to have PHP suggest
changes to your code which will ensure the best interoperability and
forward compatibility of your code. since PHP 5
</manual>

So the RFC goes: Extend the manual to specify that issues reported by
E_STRICT messages are most likely to become fatal errors in the next
major version.

I recommend at least 1.5 years notice of exactly which E_STRICT will
become E_FATAL, and document it as a front-page item at php.net

Anything less could be a real problem. Currently, I think it is fair to
say that downloads of PEAR approximately reflect the state of affairs of
the average PHP developer on the cutting edge. Yesterday, we had ~8000
downloads of PEAR packages by people using PHP 4, as opposed to ~20000
downloads of PEAR packages by people using PHP 5 and above (the majority
being PHP 5.1 by a large margin). In other words, almost a third of our
most active users are still stuck in PHP 4. The number of these users
is rapidly declining. When I began keeping track in early December
2005, almost half the downloads were PHP version 4 including a
significant minority of PHP 4.2 users (down to about 1 per day now).

At this rate, I would say it is safe to introduce some E_FATAL in about
1.5-2 years, and people will still upgrade to 6.0.

Greg

Hi Marcus,

right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so) wants the change only on a major version change like 5.0 to 6.0.

I'd back the majority over this. Changes from E_STRICT to fatal in minor
versions is out of the question; most people still use PHP 4.3.*, and this
is something you're failing to consider here.

So the RFC goes: Extend the manual to specify that issues reported by
E_STRICT messages are most likely to become fatal errors in the next
major version.

Comment from myself: To have this working we need tests. For a start
we need tests that trigger any E_STRICT present in php/zend c code.
It might as well halp to turn on E_STRICT in E_ALL but oh , i say no
more.

You already know I agree with you over that, but thousands don't.

The real problem when we're talking about moving PHP into this century is
that most people liked it as it was... We really, really need an easy
upgrade path, preferably an automated one. And we still don't have that
today.

• Steph

right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so) wants the change only on a major version change like 5.0 to 6.0.

Currently the manual says:
<manual>
2048 E_STRICT (integer) Run-time notices. Enable to have PHP suggest
changes to your code which will ensure the best interoperability and
forward compatibility of your code. since PHP 5
</manual>

So the RFC goes: Extend the manual to specify that issues reported by
E_STRICT messages are most likely to become fatal errors in the next
major version.

I would say so, as long as we define major version as "6.0" here.

regards,
Derick

Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org