On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Ferenc Kovacs wrote: > >> >> Please Lester, could you stop pretending that E_STRICT errors will crash >> your >> application and kill all the kittens? >> There are a bunch of people (myself included) who tries to write E_STRICT >> free >> code so that our application is fast and bugfree? >> Yes, there are people who ignore E_STRICT and E_DEPRECATED and I agree >> that >> having a zillion of those in the PEAR packages is a wrong thing. >> But currently it is the way to remove a feature: deprecate it both in the >> code >> and the manual, advertise in the release announcement, and remove it in >> the next >> version, hence people who are interested in keeping up with the changes >> will >> know what do they need to check and change. >> > > I'm not going to go back and list the problems. E_STRICT errors DO cause > problems running legacy code. I've had plenty of white screens until > E_STRICT was switched back off in PHP5.4! We told you that it shouldn't cause anything like that(except indirectly like taking up more memory or executing time and hitting a limit, or having a custom error handler which explicitly exit()s on an E_STRICT). We also told you to check your error log and if by any chance is a bug (what only you bumped into) then open a bugreport on http://bugs.php.net/preferably attaching a simple reproduce script, but you never did that as far as I can tell. So as far as we are concerned, E_STRICT works just fine. > Things that are just warnings in PHP5.3. the only thing that was changed in 5.4 related to E_STRICT was that E_ALL now includes E_STRICT, nothing else. 5.3 and 5.4 should behave in every other regard, if you think it isn't then please open a bugreport. > Since this is optional, some people 'opt' to ignore the warnings, just as > they ignore the E_DEPRECATED ones. yeah, those who don't wanna know or decide to ignore our runtime messages about features going away are free to do that. I can't see how and why should we change that, plus it would be a BC break. > The problem comes as in the case of $this in static functions where the > optional fixes are used to allow the code to run. PHP5.2 code works in 5.3 > if warnings are hidden, but there is no guarantee the same code will run in > 5.4 and it may well now blow up in 5.5. > the current releaseprocess RFC wouldn't allow that to happen in 5.x > > So I repeat the question, what is the point of providing a switch which > disables warning such as over the $this and then pulling the plug on it in > a later version. see above, we will (almost)always will deprecate a feature before removing it. taking away the option to silent those errors would be a pretty bad idea, and would be a major BC (to do that you would have to also change the current user error handler implementation, otherwise people would just ignore from there). removing a feature in a minor version is a different point, and it is indeed a BC break and it isn't allowed by the current releaseprocess RFC. personally I think that the current releaseprocess RFC will be either not followed all the times or we will release major versions more frequently, but time will tell. This is the exact sort of activity that I have been moaning about all > along. PHP5.3 and PHP5.4 introduced changes that should ideally have been > reserved for a major update. PHP5 code should run without problems and > complain in ANY later version of PHP5, not just some. That is what BC is > all about! For a LONG time we could even write PHP4 code that ran in PHP5. those versions were before us having formal RFCs, so features/changes was done and merged in a case-by-case basis. the major version bumps were always when the Zend Engine got rewritten, so only when the extension API was broken. the current releaseprocess in the other hand is a more stricter approach, it requires a major version bump for any userland BC break. so I think that you should be satisfied with the current situation as long as the releaseprocess is followed. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
