Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
To: Dmitry Stogov <dmitry@zend.com>, internals <internals@lists.php.net>
References: <BY2PR0201MB178440ABA11456D96DBBF8B8BF4E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Cc: Nikita Popov <nikic@php.net>, Bob Weinand <bwoebi@php.net>,
 Xinchen Hui <laruence@php.net>
Message-ID: <478356f3-cc53-d419-cfea-0a6bbd782031@gmail.com>
Date: Mon, 23 May 2016 23:54:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB178440ABA11456D96DBBF8B8BF4E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Please review the RFC.
> 
> It proposes to fix all known inconsistencies related to handling of special $this variable.
> 
> https://wiki.php.net/rfc/this_var

What is the reason behind all these changes? Does it serve some bigger
purpose? I'm not sure I currently see a reason to go to all these
lengths. Sure, you can re-assign $this and make things weird. But I
don't see why it's important to prevent it. It seems to add a lot of
code, including checks in various places that would slow down things
(and since these checks need to be done in each and every place we deal
with local variables, it is also a very brittle design - each time we
change or add anything there we'd need to remember forever to include
special case for "this").

Also notes:
1. How static __call is a thing? That looks like something that makes no
sense at all.
2. Why get_defined_vars() shouldn't show $this?

-- 
Stas Malyshev
smalyshev@gmail.com