# E_STRICT - Thread: https://externals.io/message/24352 - Original archive: https://news-web.php.net/php.internals/24352 - Started by Lukas Smith on 2006-07-12T15:56:44+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #24352 — Lukas Smith — 2006-07-12T15:56:44+00:00 URL: https://externals.io/message/24352#24352 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 --- ## #24355 — Pierre — 2006-07-12T19:11:57+00:00 URL: https://externals.io/message/24352#24355 · In reply to: #24352 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 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 --- ## #24356 — Ilia Alshanetsky — 2006-07-12T19:20:02+00:00 URL: https://externals.io/message/24352#24356 · In reply to: #24352 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 --- ## #24357 — Antony Dovgal — 2006-07-12T19:25:34+00:00 URL: https://externals.io/message/24352#24357 · In reply to: #24352 > 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 --- ## #24358 — Lukas Smith — 2006-07-12T22:37:59+00:00 URL: https://externals.io/message/24352#24358 · In reply to: #24357 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 --- ## #24359 — Antony Dovgal — 2006-07-12T22:45:48+00:00 URL: https://externals.io/message/24352#24359 · In reply to: #24358 > Antony Dovgal wrote: > > > […] > > 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. > > […] > > 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 --- ## #24360 — Lukas Smith — 2006-07-12T22:52:37+00:00 URL: https://externals.io/message/24352#24360 · In reply to: #24359 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 --- ## #24363 — Pierre — 2006-07-12T23:20:57+00:00 URL: https://externals.io/message/24352#24363 · In reply to: #24358 Hello, > 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 --- ## #24361 — Lukas Smith — 2006-07-12T23:23:59+00:00 URL: https://externals.io/message/24352#24361 · In reply to: #24363 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 --- ## #24362 — Lukas Smith — 2006-07-12T23:48:06+00:00 URL: https://externals.io/message/24352#24362 · In reply to: #24352 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 --- ## #24364 — Ilia Alshanetsky — 2006-07-13T00:15:48+00:00 URL: https://externals.io/message/24352#24364 · In reply to: #24361 > 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 --- ## #24369 — Marcus Boerger — 2006-07-13T19:19:47+00:00 URL: https://externals.io/message/24352#24369 · In reply to: #24364 Hello Ilia, Thursday, July 13, 2006, 2:15:48 AM, you wrote: > > > […] > 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 --- ## #24370 — Marcus Boerger — 2006-07-13T19:22:27+00:00 URL: https://externals.io/message/24352#24370 · In reply to: #24356 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 --- ## #24374 — Jeff Moore — 2006-07-14T05:59:57+00:00 URL: https://externals.io/message/24352#24374 · In reply to: #24352 > 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 --- ## #24378 — Sean Coates — 2006-07-14T14:29:22+00:00 URL: https://externals.io/message/24352#24378 · In reply to: #24356 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 --- ## #24383 — Greg Beaver — 2006-07-14T23:57:29+00:00 URL: https://externals.io/message/24352#24383 · In reply to: #24378 Sean Coates wrote: > Ilia Alshanetsky wrote: > > > […] > > > 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 --- ## #24668 — Derick Rethans — 2006-07-19T11:08:38+00:00 URL: https://externals.io/message/24352#24668 · In reply to: #24383 > Sean Coates wrote: > > […] > > 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 --- ## #24669 — Derick Rethans — 2006-07-19T11:11:38+00:00 URL: https://externals.io/message/24352#24669 · In reply to: #24362 > Lukas Smith wrote: > > Ok I see 2 options: > > 1) > > […] > > 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 --- ## #24860 — Lukas Smith — 2006-07-21T20:51:52+00:00 URL: https://externals.io/message/24352#24860 · In reply to: #24362 Lukas Smith wrote: > Lukas Smith wrote: > > Ok I see 2 options: > > 1) > > […] > > Pierre and Anthony seem to favor this solution. So it sounds like Derick is in this camp too. > 2) > > […] > > 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