Re: [RFC] Fix inconsistent behavior of $this variable

From: Date: Tue, 24 May 2016 08:22:51 +0000
Subject: Re: [RFC] Fix inconsistent behavior of $this variable
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-93477@lists.php.net to get a copy of this message
On 05/24/2016 11:04 AM, Stanislav Malyshev wrote:
Hi!
Keeping inconsistent behavior isn't good as well.
It's not good, but it's not also very bad. Nobody really does that, so whatever happens in these cases is mostly irrelevant.
For me it's easier to check and fix all inconsistencies at once. I may set an additional voting question about performing these run-time checks and throwing corresponding exception...
Did you test performance impact of those changes? Of course. It's invisible on real-life apps even in terms of instruction retired.
Actually, $this may be assigned to local variable in run-time only in 3 places: through $$, extract() and parse_str()/1.
For now, maybe. But every time we do something with local symbol table, we'd have to do special case for this. E.g., throretically, what if we wanted to add function to Closure that allows to access to captured scope - we'd need to special-case $this there. Etc... We shouldn't access local variables in irregular way.
This irregularity makes extract() and parse_str() to be special and they require special handling. See Nikita's RFC https://wiki.php.net/rfc/forbid_dynamic_scope_introspection
If we remove this checks, we go back to 7.0 behavior - we create a local variable $this, that has nothing in common with real internal $this stored in EX(This).
That's not good, but maybe we could make them agree in some way? What do you mean? Change the real $this to something else in the middle of the method???
In most cases it doesn't show $this in 7.0.
Right. But you're changing 7.0 behavior anyway?
Right. And I don't see reason to show $this in get_defined_vars(), because it's special, and not really a local variable. Thanks. Dmitry,

« previous php.internals (#93477) next »