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.
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.
--
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
