On 21/11/14 14:15, Rowan Collins wrote: > Lester Caine wrote on 21/11/2014 13:27: >> No - There have been several threads on deprecating things that are >> currently 'hidden' by e_strict. The confusion is created by having two >> incompatible styles of coding, and unless one brings the 'non-e_strict' >> code in to line with current practices it creates problems when other >> actions change the goal posts yet again. > > So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED > (less safe to hide). At that point, you can deal with the E_DEPRECATED > notices *and carry on ignoring E_STRICT*. > > Unless you can name an example of something which went from E_STRICT to > fatal error? If so, that specific case was a violation of process, and > should be highlighted.
IF one is working through code to fix the deprecated warnings why would one not fix the remaining e_strict. In may cases they are all in the same area of the code base? That is the whole point here ... we can't assume that the code will continue to work in the future. >> The confusion is created by having two incompatible styles of coding > > I asked this before, and you didn't answer: can you name something > which, when you fix the E_STRICT notice, makes your code incompatible > with something else? Or something which, if you *ignore* an E_STRICT > notice, refuses to work? TODAY things are a little tidier, and problems that were created over many upgrades and a lot of the problems have been fixed but it's the agro caused when third party libraries re-enabling e_strict, hosting changing settings for other reasons and problems like that. All cause problems which will only be cleared when all of the legacy code is updated ... which means making them e_strict compliant ... which IS under-way, but slow going. I have had many situations where having upgraded one library so it's then e_strict clean it has problems when used with it switched off. In my book, code runs clean, if it creates warnings/errors then it needs fixing, and so simply hiding these is what is not acceptable. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
