Re: [RFC] Fix inconsistent behavior of $this variable
| From: | Dmitry Stogov | 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!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...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.
Did you test performance impact of those changes? Of course. It's invisible on real-life apps even in terms of instruction retired.
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_introspectionActually, $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.
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???
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,In most cases it doesn't show $this in 7.0.Right. But you're changing 7.0 behavior anyway?