Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.130 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>, internals
	<internals@lists.php.net>
References: <BY2PR0201MB178440ABA11456D96DBBF8B8BF4E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <478356f3-cc53-d419-cfea-0a6bbd782031@gmail.com>
 <c35446d0-e5ca-affd-76a8-6567f795c661@zend.com>
 <e00d7e23-8388-63d2-8376-aaf02344b3fb@gmail.com>
CC: Nikita Popov <nikic@php.net>, Bob Weinand <bwoebi@php.net>, Xinchen Hui
	<laruence@php.net>
Message-ID: <37c30acc-b657-97c6-3f4f-73b5eceec198@zend.com>
Date: Tue, 24 May 2016 11:22:51 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <e00d7e23-8388-63d2-8376-aaf02344b3fb@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2016 08:23:05.6304 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1792
Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable
From: dmitry@zend.com (Dmitry Stogov)



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,