Re: PHP5 only sure .. E_STRICT?

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

Markus Tacker wrote: So, they say what's E_STRICT will not work in PHP6. What's not may become E_STRICT in future releases of PHP. No the question was as follows, in the word of Michael: "The key is we would like to know if we can rely that there are no things that throw E_STRICT in a minor version that don't work in a lower minor version" The answer to this question is no, we cannot rely on this. After the obviously heated debate with Marcus we talked in a query in the language of love (also known as german) and we got to a solution that I think is workable for us. All E_STRICT notices would start with an easily parseable string that defines the version in which the given E_STRICT notice was added. This would make it possible for us to provide a filter function that people could use in customer error handlers that would enable them to filter out any E_STRICT error messages they wish to ignore based on the lowest PHP version they want to care about. So say you support PHP 5.1.3 as the lowest PHP version for a given package. Now PHP 5.2 adds a new E_STRICT notice if you do not use feature not yet available in PHP 5.1.3. Since you do not want to increase the required version just yet you can still keep E_STRICT enabled and simply register an error handler in which you call our filter method which you configure to ignore all E_STRICT notices added since PHP 5.1.3. This solution would not require any large changes in PHP internals. They would simply need to make sure that all new E_STRICT messages follow this defined schema.

I understand your new scheme for E_STRICT and I think it's a good idea. However... Am I misunderstanding when I say that E_STRICT is meant to tell developers about possible problems with th enext major version of PHP (i.e. PHP6)? If this is what E_STRICT is really all about then I think that trying for E_STRICT compatibility in PEAR is not a good idea. The main reason is that PHP6 is not out yet and not nearly fully specified. E_STRICT is telling us about possible problems, but something which is E_STRICT in 5.2 may not be E_STRICT in 5.3 as internals may change their mind about a feature. As has been said previously, it makes no sense to be trying to hit a moving target, especially if it ends up making us follow one convention which is then removed later. It could even be worse than this. Say that one E_STRICT convention in 5.2 actually *causes* bugs in PHP and that it is realized that it is a design flaw and the E_STRICT notice is reversed in 5.3 in order to tell people about bug-prone code. The package written for E_STRICT in 5.2 would now be error prone due to our convention of having E_STRICT compliance. Now assume that we go with the version-specified E_STRICT compliance as put forth in this thread. Can you imagine how confusing this is going to be for users of PEAR? I don't relish seeing the following day in and day out: user> PEAR is supposed to be E_STRICT, why am I getting E_STRICT errors???!? dev> that package is E_STRICT compliant for PHP version 5.1.3 user> huh? Let's take this even further now. Package X is released as E_STRICT for PHP 5.1.2 and Package Y is release as E_STRICT for PHP 5.2. Now we have completely different E_STRICT guidelines for two different packages which leaves us exactly where we are now with Package X possibly throwing new E_STRICT errors which are new in PHP 5.2 from PHP 5.1.2. This will only exacerbate the problems we have. Extend this further. Package Y may *depend* on Package X, meaning that you can't be running E_STRICT for PHP 5.2 without Package X throwing errors all over the place. Now, I realize that the same could be true of any conventions that we choose, but it seems to me that basing our coding standards on a moving target like this is only going to cause us major headaches and not really solve any problems. In conclusion, while E_STRICT may be good for seeing possible problems in future versions of PHP I no longer think it's going to be useful for PEAR as a coding standard. -- Justin Patrin