Everything

php

Home » Project » Newsgroups » php.internals » E_STRICT »

E_STRICT

php.internals

Lukas Smith

20 years ago

Hi,

PEAR is currently in the process of deciding from when on we want to
mandate PHP5 as the target platform. Currently it looks like sometime in
the next 3-6 months we will likely only accept PHP5 only packages.

We are also pondering how to best approach E_STRICT. It is not feasible
for us to try to provide multiple packages per major version in order to
keep up with new E_STRICT notices that might require features not yet
available in previous versions.

Obviously one solution would be to disallow making anything an E_STRICT
notice that is not available since the first release of the given major
version. However I think that would defeat the purpose of E_STRICT.

Another solution would be to provide an easy way to filter out E_STRICT
messages based on the version they have been introduced. This would
enable a package developer to say "I want to be E_STRICT compatible upto
PHP 5.1.4". Which would mean that he could filter out any E_STRICT
notices that may for example get introduced in PHP 5.2.

Usually we slowly increase the lowest supported PHP version of packages
in order to keep the code clean and fast, without pushing our users into
a corner. So as the lowest supported PHP version increases, the
filtering could be adapted.

Adding such a filter API into PHP internals however seems like a
considerably effort. Therefore my proposal would be to simply add a
defined "header" to all E_STRICT messages that contains the PHP version
in which this E_STRICT message was added. This way PEAR could provide
its developer with a simple filter method that would take an error
message inside a customer error handler and determine if it should be
filtered out or not.

What do you guys think?

regards,
Lukas

Pierre Joye

20 years ago

Hello,

On 7/12/06, Lukas Smith <lsmith@php.net> wrote:

> Adding such a filter API into PHP internals however seems like a
> considerably effort. Therefore my proposal would be to simply add a
> defined "header" to all E_STRICT messages that contains the PHP version
> in which this E_STRICT message was added. This way PEAR could provide
> its developer with a simple filter method that would take an error
> message inside a customer error handler and determine if it should be
> filtered out or not.
>
> What do you guys think?

It sounds like killing a tank with a fly, or the other way 'round.

A E_STRICT fix does not break BC for a given package ([e]Z[end], pear,
or foobar framework). Why not simply release a bug fixes release of
this package?

I think it is reasonnable to ask users to update to support the latest
php releases (if they care about E_STRICT messages). As long as the
E_STRICT additions are loudly and clearly listed in NEWS, Changelog
and in the releases notes.

Attention, that does not mean I like to open the doors to even more
pedantic E_STRICT additions :-)

Cheers,
--Pierre

Ilia A.

20 years ago

Why not just define your own custom error handler and have it filter
out the error messages that you don't want to see... To me this would
seem like a easier approach, i would be against adding a in-language
filter for this.

Ilia Alshanetsky

Marcus Börger

20 years ago

Hello Ilia,

Wednesday, July 12, 2006, 9:20:02 PM, you wrote:

> Why not just define your own custom error handler and have it filter
> out the error messages that you don't want to see... To me this would
> seem like a easier approach, i would be against adding a in-language
> filter for this.

He is not suggesting an in-language filter here. The suggestion is
to simply send out the version as a text. If people need filtering
they would need to 'grep' the message files. If we would do anything
more then we would risk that people filter out to much and not care
anymore. Actually anyway to easily fix out anything leads to ignorance.
That reminds me on a nice phrase from rollo "Ignorance is bliss".

> Ilia Alshanetsky

Best regards,
Marcus

Sean Coates

20 years ago

Ilia Alshanetsky wrote:

> Why not just define your own custom error handler and have it filter out
> the error messages that you don't want to see... To me this would seem
> like a easier approach, i would be against adding a in-language filter
> for this.

Inability to easily determine which errors come from which version of
PHP (in userspace, or otherwise) aside, E_STRICT can't always be handled
at runtime.

I can't think of a situation in 5.1.x where this is the case, but in
5.0.x, the use of 'var' (instead of public|private|protected) caused an
E_STRICT at compile-time: before a userspace error handler could have
been registered.

... admittedly, this is abnormal, but I think we should keep it in mind
anyway.

S

Greg Beaver

20 years ago

Sean Coates wrote:

> Ilia Alshanetsky wrote:
>
>>Why not just define your own custom error handler and have it filter out
>>the error messages that you don't want to see... To me this would seem
>>like a easier approach, i would be against adding a in-language filter
>>for this.
>
>
> Inability to easily determine which errors come from which version of
> PHP (in userspace, or otherwise) aside, E_STRICT can't always be handled
> at runtime.
>
> I can't think of a situation in 5.1.x where this is the case, but in
> 5.0.x, the use of 'var' (instead of public|private|protected) caused an
> E_STRICT at compile-time: before a userspace error handler could have
> been registered.
>
> ... admittedly, this is abnormal, but I think we should keep it in mind
> anyway.

This is not entirely accurate.  A userspace error handler can catch
E_STRICT during parsing of included files and eval().  This is how we
make install-pear-nozlib.phar work with our PHP 4/5 compatible PEAR files.

Greg

Derick Rethans

20 years ago

On Fri, 14 Jul 2006, Greg Beaver wrote:

> Sean Coates wrote:
> > Ilia Alshanetsky wrote:
> >
> >>Why not just define your own custom error handler and have it filter out
> >>the error messages that you don't want to see... To me this would seem
> >>like a easier approach, i would be against adding a in-language filter
> >>for this.
> >
> >
> > Inability to easily determine which errors come from which version of
> > PHP (in userspace, or otherwise) aside, E_STRICT can't always be handled
> > at runtime.
> >
> > I can't think of a situation in 5.1.x where this is the case, but in
> > 5.0.x, the use of 'var' (instead of public|private|protected) caused an
> > E_STRICT at compile-time: before a userspace error handler could have
> > been registered.
> >
> > ... admittedly, this is abnormal, but I think we should keep it in mind
> > anyway.
>
> This is not entirely accurate.  A userspace error handler can catch
> E_STRICT during parsing of included files and eval().  This is how we
> make install-pear-nozlib.phar work with our PHP 4/5 compatible PEAR files.

Only if it is not in the main PHP script though.

Derick

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

bertrand Gugger

20 years ago

Sean Coates wrote:

> Ilia Alshanetsky wrote:
>
>>Why not just define your own custom error handler and have it filter out
>>the error messages that you don't want to see... To me this would seem
>>like a easier approach, i would be against adding a in-language filter
>>for this.
>
>
> Inability to easily determine which errors come from which version of
> PHP (in userspace, or otherwise) aside, E_STRICT can't always be handled
> at runtime.
>
> I can't think of a situation in 5.1.x where this is the case, but in
> 5.0.x, the use of 'var' (instead of public|private|protected) caused an
> E_STRICT at compile-time: before a userspace error handler could have
> been registered.

we really suffered because of that.
why you now support my presence
and others presences the same.

>
> ... admittedly, this is abnormal, but I think we should keep it in mind
> anyway.

right sean , we use php , it's due to hazard
à+

--
toggg

Antony Dovgal

20 years ago

On 12.07.2006 19:56, Lukas Smith wrote:

> Hi,
>
> PEAR is currently in the process of deciding from when on we want to
> mandate PHP5 as the target platform. Currently it looks like sometime in
> the next 3-6 months we will likely only accept PHP5 only packages.
>
> We are also pondering how to best approach E_STRICT. It is not feasible
> for us to try to provide multiple packages per major version in order to
> keep up with new E_STRICT notices that might require features not yet
> available in previous versions.
>
> Obviously one solution would be to disallow making anything an E_STRICT
> notice that is not available since the first release of the given major
> version. However I think that would defeat the purpose of E_STRICT.
>
> Another solution would be to provide an easy way to filter out E_STRICT
> messages based on the version they have been introduced. This would
> enable a package developer to say "I want to be E_STRICT compatible upto
> PHP 5.1.4". Which would mean that he could filter out any E_STRICT
> notices that may for example get introduced in PHP 5.2.

Lukas, I thought we already discussed and agreed that the only acceptable solution is NOT
to add any E_STRICT messages if the recommended way didn't exist in first release of the major version.
This apparently requires versioning and its support in PEAR.
And personally I think this is the only solution we can accept.

Adding some kind of hypercomplicated API for "filtering" E_STRICT is definitely huge overkill.

--
Wbr,
Antony Dovgal

Lukas Smith

20 years ago

Antony Dovgal wrote:

> Lukas, I thought we already discussed and agreed that the only
> acceptable solution is NOT to add any E_STRICT messages if the
> recommended way didn't exist in first release of the major version.
> This apparently requires versioning and its support in PEAR.
> And personally I think this is the only solution we can accept.

That would work fine as I pointed out in the email, but would limit the
scope of E_STRICT. The point of E_STRICT was to quickly let people know
about things that are no longer recommended/have become deprecated.
Waiting until the next major version for new features would diminish that.

> Adding some kind of hypercomplicated API for "filtering" E_STRICT is
> definitely huge overkill.

Not sure if I explained things this badly. All I requested was that the
error message contain some "header" with the php version that notice was
added.

This requires no changes in any infrastructure and the point was exactly
to make it feasible to write such a filter function for custom error
handler. The alternative would require keeping an array of the internal
error messages with the version they were added. Which would obviously
break apart if we do a simple language or other change to the given notice.

So all I am asking is that E_STRICT notices look like the following (or
something of that sort):

Strict Standards since PHP 5.0.0: Declaration of Europe::get_countries()
should be compatible with that of Scandinavia::get_countries() in - on
line 14

Instead of:

Strict Standards: Declaration of Europe::get_countries() should be
compatible with that of Scandinavia::get_countries() in - on line 14

So I dont really see where its killing a fly with a tank either. All
that people then need to do is write a simple regexp, that filters out
the version number in the E_STRICT notice and pass it off to
version_compare(). Very trivial to implement in userland, nothing more
than changing a few strings in PHP core. End of story, problem solved.

regards,
Lukas

Antony Dovgal

20 years ago

On 13.07.2006 02:37, Lukas Smith wrote:

> Antony Dovgal wrote:
>
>> Lukas, I thought we already discussed and agreed that the only
>> acceptable solution is NOT to add any E_STRICT messages if the
>> recommended way didn't exist in first release of the major version.
>> This apparently requires versioning and its support in PEAR.
>> And personally I think this is the only solution we can accept.
>
> That would work fine as I pointed out in the email, but would limit the
> scope of E_STRICT. The point of E_STRICT was to quickly let people know
> about things that are no longer recommended/have become deprecated.
> Waiting until the next major version for new features would diminish that.

Well, that's what major versions are for, right?
Bugfix releases are for bugfixes, while major versions may introduce new things and features.

>> Adding some kind of hypercomplicated API for "filtering" E_STRICT is
>> definitely huge overkill.
>
> Not sure if I explained things this badly. All I requested was that the
> error message contain some "header" with the php version that notice was
> added.
>
> This requires no changes in any infrastructure and the point was exactly
> to make it feasible to write such a filter function for custom error
> handler. The alternative would require keeping an array of the internal
> error messages with the version they were added. Which would obviously
> break apart if we do a simple language or other change to the given notice.
>
> So all I am asking is that E_STRICT notices look like the following (or
> something of that sort):
>
> Strict Standards since PHP 5.0.0: Declaration of Europe::get_countries()
> should be compatible with that of Scandinavia::get_countries() in - on
> line 14
>
> Instead of:
>
> Strict Standards: Declaration of Europe::get_countries() should be
> compatible with that of Scandinavia::get_countries() in - on line 14
>
> So I dont really see where its killing a fly with a tank either. All
> that people then need to do is write a simple regexp, that filters out
> the version number in the E_STRICT notice and pass it off to
> version_compare(). Very trivial to implement in userland, nothing more
> than changing a few strings in PHP core. End of story, problem solved.

Sorry, I still fail to see a reason to "filter" error messages..

--
Wbr,
Antony Dovgal

Lukas Smith

20 years ago

Antony Dovgal wrote:

> Well, that's what major versions are for, right?
> Bugfix releases are for bugfixes, while major versions may introduce new
> things and features.

Err we add features in minor (and even patch level) versions all the time.

> Sorry, I still fail to see a reason to "filter" error messages..

The point of E_STRICT is to encourage forward compatible code. However
as I pointed out for many developers it will not be feasible to always
target the latest version of PHP. This means that they will be coding
against some other, yet defined PHP version.

So for example

5.2.1 is the latest version
5.1.2 is the target for development.

Now there might be several new E_STRICT messages that cannot be worked
around without increasing the target development version.

This means that either:
1) I turn off E_STRICT on my development box to retain my sanity
2) I have some filter mechanism that ensures I only get E_STRICT
messages that existed in 5.1.2

What I am proposing is a tiny weeny change in PHP to make it trivial to
implement 2) in userland.

This makes sense because as time progresses I might increase my target
version. Maybe even port to a new major version. In which case I am much
better off having code that is already E_STRICT compliant uptil 5.1.2.
So there will be much less work for me to do. Code generally will be
much easier to port to new major versions that drop deprecated features.
Adoption rates of new major versions can go up. Everybody is happy.

regards,
Lukas

Pierre Joye

20 years ago

Hello,

On 7/13/06, Lukas Smith <lsmith@php.net> wrote:

> Strict Standards: Declaration of Europe::get_countries() should be
> compatible with that of Scandinavia::get_countries() in - on line 14
>
> So I dont really see where its killing a fly with a tank either.

That's why I said it is killing a tank (userland) with a fly (adding
this prefiy internally).

> All that people then need to do is write a simple regexp, that filters out
> the version number in the E_STRICT notice and pass it off to
> version_compare(). Very trivial to implement in userland, nothing more
> than changing a few strings in PHP core. End of story, problem solved.

if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with
5.2.0, update to 1.2.2 must be the way. It is the safest way, the past
shown us that some E_STRICT can be related to (sometimes critical)
bugs and we should treat them as bugs. Also, I do not like the
additions of pedantic E_STRICT, but that's another issue.

I would hate to start to add such notice detections in any of my code,
including pear.

--Pierre

Lukas Smith

20 years ago

Pierre wrote:

> if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with
> 5.2.0, update to 1.2.2 must be the way. It is the safest way, the past
> shown us that some E_STRICT can be related to (sometimes critical)
> bugs and we should treat them as bugs. Also, I do not like the
> additions of pedantic E_STRICT, but that's another issue.
>
> I would hate to start to add such notice detections in any of my code,
> including pear.

That requires that E_STRICT will not be added for any feature that is
not available since the first release of a given major version.
Otherwise you can't publish 1.2.2 without increasing the lowest
compatible php version. Which in turn is impractical as the PHP world
will never be fast enough to keep up with patch or even minor PHP
releases. Hosters are always behind 1 or 2 minor versions, at best.

regards,
Lukas

Ilia A.

20 years ago

On 12-Jul-06, at 7:23 PM, Lukas Smith wrote:

> Hosters are always behind 1 or 2 minor versions, at best.

That's an optimistic outlook, on average they are 5-6 versions behind.

Ilia Alshanetsky

Marcus Börger

20 years ago

Hello Ilia,

Thursday, July 13, 2006, 2:15:48 AM, you wrote:

> On 12-Jul-06, at 7:23 PM, Lukas Smith wrote:

>> Hosters are always behind 1 or 2 minor versions, at best.

> That's an optimistic outlook, on average they are 5-6 versions behind.

Ilia, 5 - 6 minor version behine means that hosters today would serve...
5.1 (0), 4.4 (-1), 4.3 (-2), 4.2 (-3), 4.1 (-4), 4.0 (-5)
...wow php 4.0.something or even php 3. I guess you mean bugfix releases
here. That means given we have 5.1.4 and 4.4.3 hosters serve something
between 4.3.8 to 5.1.0.

Just to clearify because i had the feeling people are getting our
version scheme wrong. It is (major) . (minor) . (bugfix)

marcus

Lukas Smith

20 years ago

Lukas Smith wrote:

Ok I see 2 options:

1)

> Obviously one solution would be to disallow making anything an E_STRICT
> notice that is not available since the first release of the given major
> version.

Pierre and Anthony seem to favor this solution.

2)

> Adding such a filter API into PHP internals however seems like a
> considerably effort. Therefore my proposal would be to simply add a
> defined "header" to all E_STRICT messages that contains the PHP version
> in which this E_STRICT message was added. This way PEAR could provide
> its developer with a simple filter method that would take an error
> message inside a customer error handler and determine if it should be
> filtered out or not.

From IRC discussions and the PEAR ML I think Michael and Marcus favor
this solution. I also prefer this solution.

regards,
Lukas

Derick Rethans

20 years ago

On Thu, 13 Jul 2006, Lukas Smith wrote:

> Lukas Smith wrote:
>
> Ok I see 2 options:
>
> 1)
> > Obviously one solution would be to disallow making anything an E_STRICT
> > notice that is not available since the first release of the given major
> > version.
>
> Pierre and Anthony seem to favor this solution.

E_STRICT is meant as a tool for us (php developers) to signal possible
bad usage of the language and/or possible BC breaks in the future.
Therefore it's perfectly valid to require the update of a package in
order to be E_STRICT compatible with a later PHP version. I doubt that
(for e_strict) there won't be a solution that works on older PHP
versions. It is *that* that we need to make sure doesn't happen then and
we're in the clear.

Derick

Lukas Smith

20 years ago

Lukas Smith wrote:

> Lukas Smith wrote:
>
> Ok I see 2 options:
>
> 1)
>> Obviously one solution would be to disallow making anything an
>> E_STRICT notice that is not available since the first release of the
>> given major version.
>
> Pierre and Anthony seem to favor this solution.

So it sounds like Derick is in this camp too.

> 2)
>> Adding such a filter API into PHP internals however seems like a
>> considerably effort. Therefore my proposal would be to simply add a
>> defined "header" to all E_STRICT messages that contains the PHP
>> version in which this E_STRICT message was added. This way PEAR could
>> provide its developer with a simple filter method that would take an
>> error message inside a customer error handler and determine if it
>> should be filtered out or not.
>
>  From IRC discussions and the PEAR ML I think Michael and Marcus favor
> this solution. I also prefer this solution.

Any more opinions on this?
I guess there is also option 3) aka "I dont care, lets not worry about it"

regards,
Lukas

Jeff Moore

20 years ago

On Jul 12, 2006, at 11:56 AM, Lukas Smith wrote:

> Therefore my proposal would be to simply add a defined "header" to all
> E_STRICT messages that contains the PHP version in which this E_STRICT
> message was added.

Hi Lukas,

An alternative might be to implement numerical error code identifiers
and then allocate them sequentially.  Identifying error messages
introduced in future versions could be done by comparing the error code
number against the last defined code in a known version.  I'm not sure
about the importance of the use case of identifying the version
introduced, but having error codes might have other merits.

Best Regards,

Jeff