On 21/11/14 12:36, Jan Schneider wrote: > > Zitat von Lester Caine <les...@lsces.co.uk>: > >> On 21/11/14 11:31, Rowan Collins wrote: >>>> I know I sound like a broken record, but this is EXACTLY the same >>>> problem as e_strict! It is all very well saying old code can still run >>>> if you hide the the warnings and ERRORS, but you have to spend the time >>>> fixing each and every warning simply to ensure that it will work on the >>>> next release ... hiding things does not work. >>>> >>>> And I still run my own version of PEAR to get around the e_strict >>>> problems! >>> >>> To reply with a broken record of my own: E_STRICT does not indicate code >>> that will break in a future version. Hiding E_STRICT notices will have >>> absolutely no detrimental effect on your code, now or in the future. It >>> is up to you if you want to improve the code by following the hints, or >>> ignore them because the code works fine. >>> >>> So, no this is not at all similar to the "problem" of E_STRICT, because >>> that problem is not real. >> >> So everything that currently requires e_strict disabled to allow it to >> work will continue to work in PHP7? Including the parts that have now >> been marked for removal since being deprecated since PHP5.3? > > You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED in > an earlier minor PHP release, a feature/construct cannot be removed from > PHP.
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. >> In practice ... NO the code does not work fine UNLESS you ensure that >> all of the infrastructure is still using old versions of libraries. And >> even then we still get white screen responses with changes of PHP >> versions. My point is that on one hand people are COMPLAINING that code >> such as PHP 4 Constructors is not being updated and then ALSO claiming >> that we don't need to ... PLEASE can we have a level playing field to >> code to! > > I still don't get get what problem this RFC is actually going to solve? > I don't see a problem. Yes, PHP4 constructors are are old and should no > longer be used. But there is no problem still supporting them. Raise an > E_DEPRECATED for those, and be done with it. It's following through on that with the rest of the infrastructure which is the important thing. Once something is deprecated again simply hiding the error is not going to get legacy code up to date so it then fails when the target is actually removed. Perhaps what I AM asking, is just that we need a clean roadmap for PHP7 on just what will be retained. Some of that may well need a PHP5.7 to deprecate it and I'm not against this particular tidy up, but it does need to be planned in the right way. -- 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
