Re: PHP5 only sure .. E_STRICT?

Justin Patrin wrote:

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

Justin Patrin wrote:

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.

the point is to make it easier to port the code and to simply ensure that the code is as much forward compatible as possible. this is why i still think that E_STRICT is a worthy goal, if we can control it in a manner as I suggested.

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.

well php is not bug free .. for example the streams api was broken and fixed in 5.0.x releases. we would simply need to mark these releases as broken in the given package.xml's

True, but that's not really the major thrust of what I was saying. Not only will users be confused about it due to version differences (although this is something we can deal with if we want to) but having packages have different E_STRICT PHP versions is going to make compliance very hard to test reliably. I don't think that we should ignore E_STRICT, just that it's a bit early to be worrying about E_STRICT compliance when PHP6 is so far in the future. Developers should certainly be checking their code with E_STRICT regularly to see what possible problems they may have, but using it as our coding standard is going to make things pretty crazy. If PEAR was one package or product maybe this would be ok as it could all be updated to a newer version at once, but having parts of PEAR compliant with different versions of E_STRICT just seems like we're asking for trouble to me.

I humbly disagree :) I think it makes sense to try to make the code as forward compatible as possible. PEAR users can also use this filter mechanism on their dev boxes and obviously disable E_STRICT on their production boxes. regards, Lukas