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
Hello,
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 allE_STRICTmessages that contains the PHP version
in which thisE_STRICTmessage 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
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
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
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_STRICTcan'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_STRICTat 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
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_STRICTcan'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_STRICTat 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_STRICTduring 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
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 newE_STRICTnotices 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 beE_STRICTcompatible upto
PHP 5.1.4". Which would mean that he could filter out anyE_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
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add anyE_STRICTmessages 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_STRICTis
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 wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add anyE_STRICTmessages 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 ofE_STRICTwas 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_STRICTis
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_STRICTnotices 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 14Instead of:
Strict Standards: Declaration of Europe::get_countries() should be
compatible with that of Scandinavia::get_countries() in - on line 14So 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 theE_STRICTnotice 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
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:
- I turn off
E_STRICTon my development box to retain my sanity - 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
Hello,
Strict Standards: Declaration of Europe::get_countries() should be
compatible with that of Scandinavia::get_countries() in - on line 14So 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 theE_STRICTnotice 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
Pierre wrote:
if foo-1.2.1 is
E_STRICTcompliant 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 someE_STRICTcan 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
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
Hello Ilia,
Thursday, July 13, 2006, 2:15:48 AM, you 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 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.
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 allE_STRICTmessages that contains the PHP version
in which thisE_STRICTmessage 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
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_STRICTnotice 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 allE_STRICTmessages that contains the PHP
version in which thisE_STRICTmessage 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
Therefore my proposal would be to simply add a defined "header" to all
E_STRICTmessages that contains the PHP version in which thisE_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