E_STRICT

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

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

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

Lukas Smith wrote:

Ok I see 2 options:

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 wrote:

Lukas Smith wrote:

Ok I see 2 options:

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.

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