Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119699
Message-ID: <a0973bd2-8c1d-c3b3-73a1-6909e2b72db1@gmail.com>
Date: Tue, 14 Mar 2023 22:44:11 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Content-Language: en-GB
To: internals@lists.php.net
References: <8a9a04b3-45e6-47dd-dee8-0f524e49bd37@gmail.com>
 <CAPyj-LDf6exN2R15Q26+xoNu9vtuD7hu4sFvaTPbPDe4mrQCpA@mail.gmail.com>
In-Reply-To: <CAPyj-LDf6exN2R15Q26+xoNu9vtuD7hu4sFvaTPbPDe4mrQCpA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Brainstorming idea: inline syntax for lexical
 (captured) variables
From: rowan.collins@gmail.com (Rowan Tommins)

On 14/03/2023 21:23, Ilija Tovilo wrote:
> One thing to note is that, as I've learned recently, anonymous classes
> can actually be instantiated at a later point with some tricks.
>
> https://3v4l.org/2OcmP


Huh, that's freaky... I guess this is all a reminder that these really 
are anonymous *classes*, not anonymous *instances* - at some point, a 
class entry needs to be generated.

I guess you'd have to generate a new class entry every time the "new 
class" line was run, and inject the extra values into that.


If it was limited to capturing scalars and arrays, you could treat it as 
a kind of macro expansion, i.e. this ...

$example = new class {
     public $inner = $^outer;
}

... could be a sort of sugar for:

eval(
     sprintf(
         'return new class {
             public $inner = %s;
         };',
         var_export($outer, true)
     )
);

Which is valid code, if not particularly efficient: https://3v4l.org/sQaUS

That doesn't allow for normal object semantics, though, so is probably a 
non-starter.


> This could also prove technically challenging. Currently, property
> defaults are constant ASTs and unique per class (not object).


As I understand it, the main reason object properties weren't included 
in the "new in initializers" RFC was the problem of when side effects 
would occur: 
https://wiki.php.net/rfc/new_in_initializers#unsupported_positions 
That's not an issue here, because we're not *creating* an object, we're 
"just" resolving the $^outer token to an existing zval, and storing it 
in the default property table.

It might actually be easier to *only* allow capture into property 
initialisers:

1. Create a new class entry without any property default (or clone a 
pre-compiled base)
2. Add the captured values to the default property table
3. Create an instance, run its constructor, etc, as currently

Or even:

1. Use the existing logic to create an anonymous class entry ignoring 
the capturing syntax
2. Create an instance, initialise normal defaults, but don't run the 
constructor yet
3. Push the captured values directly into the *instance* properties
4. Run the constructor


I'm probably in way over my head here, so I should probably stop here, 
in the hope that it will inspire someone more knowledgeable to come up 
with something workable, because I'd really love for anonymous classes 
to be more flexible than they are.

Regards,

-- 
Rowan Tommins
[IMSoP]