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,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to