Nikita Popov wrote on 12/02/2015 23:33:
On Fri, Feb 13, 2015 at 12:06 AM, Ferenc Kovacs <tyr...@gmail.com
<mailto:tyr...@gmail.com>> wrote:
adding the E_DEPRECATED was only about the assuming $this
behavior: https://wiki.php.net/rfc/incompat_ctx
While the RFC may claim that, the way it was implemented will throw
E_DEPRECATED irregardless whether $this is used or not. As such all
static calls to non-static methods will currently throw a deprecation,
if the call happens from a non-static method. In practice you can
leave off that last restriction, because in codebases that don't use
"static" annotations for PHP 4 compatibility obviously all methods are
non-static, so always E_DEPRECATED will be thrown instead of E_STRICT.
Reverting this to E_STRICT means we undeprecate this again, which is
something I am certainly against.
and the original plan for removing this behavior was simply to
remove/not assume $this:
"Even though I think an error at call site would be the most
useful to the user, the most sensible option is to just have $this
=== null inside the callee, like when you do"
The RFC is not very clear on what is supposed to be implemented. I'm
proposing to go with the option "most useful to the user" here, while
you suggest to use what's referred to as "the most sensible option".
However, I am not willing to invest more time in this issue. I have
decided that I will implement this by nulling out $this and keeping
the error levels exactly as they are right now (a mix of E_STRICT and
E_DEPRECATED). I would have liked consistent error levels and I would
have really liked being nice to the user and giving him a error at the
call site, instead of a weird undefined variable notice which is even
suppressed by default. But in the end this is just not important
enough for me to put up with all the php internals crap.
I'm sorry this discussion has become so frustrating for you. Personally,
I think consistent errors would be great; and I agree that the aim
should be to give the user a helpful notice.
Whether that should be E_DEPRECATED or E_STRICT is a minor detail, and
depends on us predicting the future. My personal prediction is that this
will go the way of "var", and remain as a discouraged but supported
feature, but it's really not that big a deal.
Regards,
--
Rowan Collins
[IMSoP]
