Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119700
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773
Mime-Version: 1.0
Message-ID: <f0b6ce61-9a9f-4598-aa97-df6ceef6be28@app.fastmail.com>
In-Reply-To: <8a9a04b3-45e6-47dd-dee8-0f524e49bd37@gmail.com>
References: <8a9a04b3-45e6-47dd-dee8-0f524e49bd37@gmail.com>
Date: Tue, 14 Mar 2023 17:54:40 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Brainstorming idea: inline syntax for lexical (captured)
 variables
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 14, 2023, at 3:41 PM, Rowan Tommins wrote:
> Hi all,
>
> I have been pondering for a while how to improve the anonymous class=20
> syntax to allow "capturing" of values from the outer scope, and came u=
p=20
> with the idea of a special variable marker for "lexically captured=20
> variable" - instead of $foo, you would write $!foo or $^foo (I quite=20
> like the "upwardness" of $^).
>
> To give a simple example, values can only pass into the anonymous clas=
s=20
> via its constructor, like this:
>
> function foo(int $outer) {
>  =C2=A0=C2=A0=C2=A0 return new class($outer) {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 public function __construc=
t(
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr=
ivate int $myProp
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ) {}
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 public function getIt() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn $this->myProp;
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>  =C2=A0=C2=A0=C2=A0 };
> }
>
> The idea is that you would instead be able to reference an outer=20
> variable directly anywhere in the declaration, removing a lot of=20
> boilerplate:
>
> function foo(int $outer) {
>  =C2=A0=C2=A0=C2=A0 return new class {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 public function getIt() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn $^outer;
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>  =C2=A0=C2=A0=C2=A0 };
> }
>
> The outer variable would be captured by value, and carried around with=20
> the instance, like existing closures.
>
> I suggest it is also treated as readonly, and visible strictly in the=20
> lexical definition, not generally in private scope (it couldn't be=20
> referenced from an applied trait, for instance).
>
> Using it to initialise a property or local variable would allow you to=20
> give it an explicit scope, while still avoiding the constructor:
>
> function foo(int $outer) {
>  =C2=A0=C2=A0=C2=A0 private $inner =3D $!outer;
>  =C2=A0=C2=A0=C2=A0 return new class {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 public function getIt() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $t=
his->inner++;
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn $this->inner;
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>  =C2=A0=C2=A0=C2=A0 };
> }
>
>
> It then occurred to me that the same syntax could be used in=20
> multi-statement anonymous functions instead of an explicit use()=20
> statement. This strikes a different balance between conciseness and=20
> explicitness than full automatic capture:
>
> $before =3D function($x) use ($y, $z) {
>  =C2=A0=C2=A0=C2=A0 $a =3D $x * $y;
>  =C2=A0=C2=A0=C2=A0 return do_something($a, $z);
> }
> $after =3D function($x) {
>  =C2=A0=C2=A0=C2=A0 $a =3D $x * $^y;
>  =C2=A0=C2=A0=C2=A0 return do_something($a, $^z);
> }
>
>
> To keep this message short, I've put some more examples and thoughts=20
> into a GitHub Gist here:=20
> https://gist.github.com/IMSoP/4157af05c79b3df4c4853f5a58766341
>
> I'd be interested to hear anyone's thoughts - is this a promising idea=20
> to explore, or have I gone completely off the rails?

Pourque no los dos?

Ilija's point about implementation challenges concerns me, but my initia=
l thought is that I quite like it.  I've run into the same issue with ca=
pturing into anon classes and wished for something like this.

As you were describing it, I was also thinking of the potential implicat=
ions for closures, too.  That sounds... kinda fun. :-)  However, I agree=
 with Ilija that the original proposal to just do it automatically would=
 be better; and if that didn't pass, I have no expectation that an alter=
nate with a funky new syntax would do any better.

The other concern is that this introduces a whole new realm of possible =
behaviors; like, what does $^foo mean in a non-anon-class context?  Does=
 it?  Could it be made to mean something in the future?  Does it become =
an alternate syntax for `global`?  What else could we do with it?  This =
rabbit hole goes very deep very quickly, and pursuing this for anon clas=
ses without considering the longer-term implications seems both impossib=
le (because people will ask) and unwise.

--Larry Garfield