Everything

php

[RFC] E_STRICT

php.internals

Marcus Börger

20 years ago

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.

RFC = Comments?

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.

Best regards,
Marcus

Greg Beaver

20 years ago

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

Steph

20 years ago

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.

<snip />

> 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

Sara Golemon

20 years ago

>>  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 that'd be a major version bump for them. :)

-Sara

Let them eat cake.

Steph

20 years ago

>> 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 that'd be a major version bump for them. :)

If they'd had E_STRICT messages in 4.3.*, sure...

> -Sara
>
> Let them eat cake.

... those fat bastards :)

- Steph

Derick Rethans

20 years ago

On Wed, 31 May 2006, Marcus Boerger wrote:

>   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

Antony Dovgal

20 years ago

On 31.05.2006 11:46, Derick Rethans wrote:

> On Wed, 31 May 2006, Marcus Boerger wrote:
>
>>   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.

Yes.
So that E_STRICT notices introduced in 6.x will become E_FATALs only in 7.0 and so on.

--
Wbr,
Antony Dovgal

Daniel Convissor

20 years ago

On Wed, May 31, 2006 at 06:24:35PM +0400, Antony Dovgal wrote:

>
> So that E_STRICT notices introduced in 6.x will become E_FATALs only in 7.0
> and so on.

That's pretty much what I was going to say.

To be clear, unlike the commit that was recently reverted, E_STRICT should
never be moved into E_ALL.  What should change is the type of error the
behaviors trigger.

So, something from PHP 4 that triggers an E_STRICT in PHP 5 should trigger
an E_WARNING (or whatever) in PHP 6.

This leaves E_STRICT available for use in PHP 6 to tag deprecated items
from PHP 5 that will trigger E_WARNINGS in PHP 7.

And on and on...

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409