Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92463
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 217.70.178.86 cause and error)
To: internals@lists.php.net
References: <CAL=_i_==wsq5j2Jf1QdusxaCBU8COX3eJvZY+puD8zH1zCrTXw@mail.gmail.com>
 <CAF+90c_3Sj7zqJaQy6u=3RQOxh+Y7uZ7Eo-pW2m=Ty95npfjfA@mail.gmail.com>
Message-ID: <57163F32.5010905@hoa-project.net>
Date: Tue, 19 Apr 2016 16:22:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAF+90c_3Sj7zqJaQy6u=3RQOxh+Y7uZ7Eo-pW2m=Ty95npfjfA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope
From: ivan.enderlin@hoa-project.net (Ivan Enderlin)

On 19/04/16 16:18, Nikita Popov wrote:
> On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins <pthreads@pthreads.org> wrote:
>
>> Morning Internals,
>>
>>      Please review the following RFC:
>>
>>      https://wiki.php.net/rfc/lexical-anon
>>
>>      A look at the patch from those of you that do that would be good :)
>>
> Hey Joe,
>
> The syntax and semantics proposed in this RFC don't sit quite well with me.
> Especially the fact that a use($foo) on the class is then used as
> $this->foo in methods is non-intuitive to me, as it differs from how the
> same syntax behaves on closures. I'd like to suggest an alternative syntax:
>
> $foo = 42;
> return new class {
>      private $bar = $foo;
>      public function getBar() { return $this->bar; }
> }
>
> That is, allow properties inside the anonymous class to be initialized
> based on values from the surrounding scope. This is more explicit (clearly
> shows that a property is being created), it allows explicit control over
> the visibility and, depending on implementation, might be more flexible
> with regards to the values it accepts. It probably doesn't make sense to
> restrict this to specific expressions, so all of
>
> return new class {
>      private $a = $var;
>      private $b = $obj->prop;
>      private $d = $obj->prop ?? 'default';
>      // ...
> }
>
> could be fine.
I could not express better than you, so big +1 for your proposal so far.