Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126823
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
 <fdeeec46-55c0-409e-a230-f04c3af23464@app.fastmail.com>
In-Reply-To: <fdeeec46-55c0-409e-a230-f04c3af23464@app.fastmail.com>
Date: Tue, 18 Mar 2025 10:45:59 -0300
Message-ID: <CANCsWvf8mRCPNEbrnVUJ6X89cvGkn1umEB9K6zbOSkHOw=RkQQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a4fb0f06309e20c1"
From: talyssonlima5@gmail.com (Talysson Lima)

--000000000000a4fb0f06309e20c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I say it's bright, you call it dark.
If I choose the east, you push for the south.
You=E2=80=99re not seeking a path, just a fight...
Debating with you? Not worth the time!

Em ter., 18 de mar. de 2025 =C3=A0s 03:00, Larry Garfield <larry@garfieldte=
ch.com>
escreveu:

> On Sun, Mar 16, 2025, at 4:24 AM, Edmond Dantes wrote:
> > Good day, everyone. I hope you're doing well.
> >
> > https://wiki.php.net/rfc/true_async
> >
> > Here is a new version of the RFC dedicated to asynchrony.
> >
> > Key differences from the previous version:
> >
> > * The RFC is not based on Fiber; it introduces a separate class
> > representation for the asynchronous context.
>
> I'm unclear here.  It doesn't expose Fibers at all, or it's not even
> touching the C code for fibers internally?  Like, would this render the
> existing Fiber code entirely vestigial, not just its API?
>
> > * All low-level elements, including the Scheduler and Reactor, have
> > been removed from the RFC.
> > * The RFC does not include Future, Channel, or any other primitives,
> > except those directly related to the implementation of structured
> > concurrency.
> >
> > The new RFC proposes more significant changes than the previous one;
> > however, all of them are feasible for implementation.
> >
> > I have also added PHP code examples to illustrate how it could look
> > within the API of this RFC.
> >
> > I would like to make a few comments right away. In the end, the Kotlin
> > model lost, and the RFC includes an analysis of why this happened. The
> > model that won is based on the Actor approach, although, in reality,
> > there are no Actors, nor is there an assumption of implementing
> > encapsulated processes.
> >
> > On an emotional level, the chosen model prevailed because it forces
> > developers to constantly think about how long coroutines will run and
> > what they should be synchronized with. This somewhat reminded me of
> > Rust=E2=80=99s approach to lifetime management.
>
> Considering that lifetime management is one of the hardest things in Rust
> to learn, that's not a ringing endorsement.
>
> > Another advantage I liked is that there is no need for complex syntax
> > like in Kotlin, nor do we have to create separate entities like
> > Supervisors and so on. Everything is achieved through a simple API that
> > is quite intuitive.
>
> I'll be honest... intuitive is not the term I'd use.  In fact, I didn't
> make it all the way through the RFC before I got extremely confused about
> how it all worked.
>
> First off, it desperately needs an "executive summary" section up at the
> top.  There's a *lot* going on, and having a big-picture overview would
> help a ton.  (For examples, see property hooks[1] and pattern
> matching[2].)
>
> Second, please include realistic examples.  Nearly all of the examples ar=
e
> contrived, which doesn't help me see how I would actually use async
> routines or what the common patterns would be, and I therefore cannot
> evaluate how well the proposal treats those common cases.  The first
> non-foobar example includes a comment "of course you should never do it
> like this", which makes the example rather useless.  And the second is
> built around a code model that I would never, ever accept into a code bas=
e,
> so it's again unhelpful.  Most of the RFC also uses examples that... have
> no return values.  So from reading the first half of it, I honestly
> couldn't tell you how return values work, or if they're wrapped in a Futu=
re
> or something.
>
> Third, regarding syntax, I largely agree with Tim that keywords are bette=
r
> than functions.  This is very low-level functionality, so we can and shou=
ld
> build dedicated syntax to make it as robust and self-evident (and IDE
> friendly) as possible.
>
> That said, even allowing for the async or await or spawn keywords, I got
> super confused when the Scope object was introduced.  So would the
> functions/keywords be shortcuts for some of the common functionality of a
> Scope object?  If not, what's the actual difference?  I got lost at that
> point.
>
> The first few sections of the RFC seem to read as "this RFC doesn't
> actually work at all, until some future RFC handles this other part."
> Which... no, that's not how this works. :-)
>
> As someone that has not built an async framework before (which is 99.9% o=
f
> PHP developers, including those on this list), I do not see the point of
> half the functionality here.  Especially the BoundedScope.  I see no reas=
on
> for it to be separate from just any other Scope.  What is the difference
> between scope and context?  I have no clue.
>
> My biggest issue, though, is that I honestly can't tell what the mental
> model is supposed to be.  The RFC goes into detail about three different
> async models.  Are those standard terms you're borrowing from elsewhere, =
or
> your own creation?  If the former, please include citations.  I cannot
> really tell which one the "playpen" model would fit into.  I... think
> bottom up, but I'm not sure.  Moreover, I then cannot tell which of those
> models is in use in the RFC.  There's a passing reference to it being
> bottom up, I think, but it certainly looks like the No Limit model.
> There's a section called structured concurrency, but what it describes
> doesn't look a thing like the playpen-definition of structured concurrenc=
y,
> which as noted is my preference.  It's not clear why the various positive=
s
> and negatives are there; it's just presented as though self-evident.  Why
> does bottom up lead to high memory usage, for instance?  That's not clear
> to me.  So really... I have no idea how to think about any of it.
>
> Sorry, I'm just totally lost at this point.
>
> As an aside: I used "spawn" as a throw-away keyword to avoid using "await=
"
> in a previous example.  It's probably not the right word to use in most o=
f
> these cases.
>
> I know some have expressed the sentiment that tightly structured
> concurrency is just us not trusting developers and babysitting them.  To
> which I say... YES!  The overwhelming majority of PHP developers have no
> experience writing async code.  Their odds of getting it wrong and doing
> something inadvertently stupid by accident through not understanding some
> nuance are high.  And I include myself in that.  MY chances of
> inadvertently doing something stupid by accident are high.  I *want* a
> design that doesn't let me shoot myself in the foot, or at least makes it
> difficult to do.  If that means I cannot do everything I want to... GOOD!
> Humans are not to be trusted with manually coordinating parallelism.  We'=
re
> just not very good at it, as a species.
>
> Broadly speaking, I can think of three usage patterns for async in PHP
> (speaking, again, as someone who doesn't have a lot of async experience, =
so
> I may be missing some):
>
> 1. Fan-out.  This is the "fetch all these URLs at once" type use case,
> which in most cases could be wrapped up into a para_map() function.  (Whi=
ch
> is exactly what Rust does.)
> 2. Request handlers, for persistent-process servers.  Would also apply fo=
r
> a queue worker.
> 3. Throw it over the wall.  This would be the logging example, or sending
> an email on some trigger, etc.  Importantly, these are cases where there =
is
> no result needed from the sub-routine.
>
> I feel like those three seem to capture most reasonable use cases, give o=
r
> take some details.  (And, of course, many apps will include all three in
> various places.)  So any proposal should include copious examples of how
> those three cases would look, and why they're sufficiently ergonomic.
>
> A playpen model can handle both 1 and 2.  In fan out, you want the "Wait
> all" logic, but then you also need to think about a Future object or
> similar.  In a request handler, you're spawning an arbitrary number of
> coroutines that will terminate, and you probably don't care if they have =
a
> return value.
>
> It's the "throw over the wall" cases where a playpen takes more work.  As
> I showed previously, it can be done.  It just takes a bit more setup.  Bu=
t
> if that is too much for folks, I offer a compromise position.  Again, jus=
t
> spitballing the syntax specifics:
>
> // Creates an async scope, in which you can create coroutines.
> async {
>
>   // Creates a new coroutine that MAY last beyond the scope of this block=
.
>   // However, it MUST be a void-return function, indicating that it's
> going to
>   // do work that is not relevant to the rest of this block.
>   spawn func_call(1, 2, 3);
>
>   // Creates a new coroutine that will block at the end of this async
> block.
>   // The return value is a future for whatever other_function() will
> return.
>   // $future may be used as though it were the type returned, but trying
>   // to read it will block until the function completes.  It may also hav=
e
> other
>   // methods on it, not sure.
>   $future =3D start other_function(4, 5, 6);
>
>   // Queues a coroutine to get called after all "start"ed coroutines have
> completed
>   // and this block is about to end.  Its return value is discarded.
> Perhaps it should be
>   // restricted to void-return, not sure.  In this case it doesn't hurt
> anything.
>   defer cleanup(7, 8, 9);
>
>   // Do nothing except allow other coroutines to switch in here if they
> want.
>   suspend;
>
>   // Enqueues this coroutine to run in 100 ms, or slightly thereafter
> whenever the scheduler gets to it.
>   timeout 100ms something(4, 5, 6);
>
> } // There is an implicit wait-all here for anything start-ed, but not fo=
r
> spawn-ed.
>
> I honestly cannot see a use case at this point for starting coroutines in
> arbitrary scopes.  Only "current scope" and "global scope, let it escape.=
"
> That maps to "start" and "spawn" above.  If internally "spawn" gets
> translated to "start in the implicit async block that is the entire
> application", so that those coroutines will still block the whole script
> from terminating, that is not a detail most devs will care about.  (Which
> also means in the global async scope, spawn and start are basically
> synonymous.)
>
> I can see the need for cancellation, which means probably we do need a
> scope object to represent the current async block.  However, that's just =
a
> cancel() method, which would propagate to any child.  Scheduling it can b=
e
> handled by the timeout command.  At this point, I do not see the use case
> for anything more advanced than the above (except for channels, which as =
I
> argued before could make spawn unnecessary).  There may be a good reason
> for it, but I don't know what it is and the RFC does not make a compellin=
g
> argument for why anything more is needed.
>
> I could see an argument that async $scope { ... } lets you call all of th=
e
> above keywords as methods on $scope, and the keywords are essentially a
> shorthand for "this method on the current scope".  But you could also pas=
s
> the scope object around to places if you want to do dangerous things.  I'=
m
> not sure if I like that, honestly, but it seems like an option.
>
> Elsewhere in the thread, Tim noted that we should unify the function call
> vs closure question.  I used straight function calls above for simplicity=
,
> but standardizing on a closure also makes sense.  Related, I've been
> talking with Arnaud about trying to put Partial Function Application
> forward again[3], assuming pipes[4] pass.  If we follow the previous mode=
l,
> then it would implicitly provide a way to turn any function call into a
> delayed function call:
>
> function foo(int $a, int $b) { ... }
>
> foo(4, 5); // Calls foo() right now
> foo(4, 5, ...); // Creates a 0-argument closure that will call foo(4, 5)
> when invoked.
>
> Basically the latter is equivalent to:
> fn() =3D> foo(4, 5);
>
> A 0-argument closure (because all arguments are already captured) goes by
> the delightful name "thunk" (as in the past tense of think, if you don't
> know English very well.)  That likely wouldn't be ideal, but it would mak=
e
> standardizing start/spawn on "thou shalt provide a closure" fairly
> straightforward, as any function could trivially be wrapped into one.
>
> That's not necessarily the best way, but I mention it to show that there
> are options available if we allow related features to support each other
> synergistically, which I always encourage.
>
> Like Tim, I applaud you're commitment to this topic and willingness to
> work with feedback.  But the RFC text is still a long way from a model th=
at
> I can wrap my head around, much less support.
>
> [1] https://wiki.php.net/rfc/property-hooks
> [2] https://wiki.php.net/rfc/pattern-matching
> [3] https://wiki.php.net/rfc/partial_function_application
> [4] https://wiki.php.net/rfc/pipe-operator-v3
>
> --Larry Garfield
>

--000000000000a4fb0f06309e20c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If I say it&#39;s bright, you call it dark.<br>If I choose=
 the east, you push for the south.<br>You=E2=80=99re not seeking a path, ju=
st a fight...<br>Debating with you? Not worth the time!</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">Em ter., 18 de mar. de 2025 =C3=A0s 03:00, Larry Garfield &lt;<a href=3D"=
mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; escreveu:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 16, 202=
5, at 4:24 AM, Edmond Dantes wrote:<br>
&gt; Good day, everyone. I hope you&#39;re doing well.<br>
&gt;<br>
&gt; <a href=3D"https://wiki.php.net/rfc/true_async" rel=3D"noreferrer" tar=
get=3D"_blank">https://wiki.php.net/rfc/true_async</a><br>
&gt;<br>
&gt; Here is a new version of the RFC dedicated to asynchrony.<br>
&gt;<br>
&gt; Key differences from the previous version:<br>
&gt;<br>
&gt; * The RFC is not based on Fiber; it introduces a separate class <br>
&gt; representation for the asynchronous context.<br>
<br>
I&#39;m unclear here.=C2=A0 It doesn&#39;t expose Fibers at all, or it&#39;=
s not even touching the C code for fibers internally?=C2=A0 Like, would thi=
s render the existing Fiber code entirely vestigial, not just its API?<br>
<br>
&gt; * All low-level elements, including the Scheduler and Reactor, have <b=
r>
&gt; been removed from the RFC.<br>
&gt; * The RFC does not include Future, Channel, or any other primitives, <=
br>
&gt; except those directly related to the implementation of structured <br>
&gt; concurrency.<br>
&gt;<br>
&gt; The new RFC proposes more significant changes than the previous one; <=
br>
&gt; however, all of them are feasible for implementation.<br>
&gt;<br>
&gt; I have also added PHP code examples to illustrate how it could look <b=
r>
&gt; within the API of this RFC.<br>
&gt;<br>
&gt; I would like to make a few comments right away. In the end, the Kotlin=
 <br>
&gt; model lost, and the RFC includes an analysis of why this happened. The=
 <br>
&gt; model that won is based on the Actor approach, although, in reality, <=
br>
&gt; there are no Actors, nor is there an assumption of implementing <br>
&gt; encapsulated processes.<br>
&gt;<br>
&gt; On an emotional level, the chosen model prevailed because it forces <b=
r>
&gt; developers to constantly think about how long coroutines will run and =
<br>
&gt; what they should be synchronized with. This somewhat reminded me of <b=
r>
&gt; Rust=E2=80=99s approach to lifetime management.<br>
<br>
Considering that lifetime management is one of the hardest things in Rust t=
o learn, that&#39;s not a ringing endorsement.<br>
<br>
&gt; Another advantage I liked is that there is no need for complex syntax =
<br>
&gt; like in Kotlin, nor do we have to create separate entities like <br>
&gt; Supervisors and so on. Everything is achieved through a simple API tha=
t <br>
&gt; is quite intuitive.<br>
<br>
I&#39;ll be honest... intuitive is not the term I&#39;d use.=C2=A0 In fact,=
 I didn&#39;t make it all the way through the RFC before I got extremely co=
nfused about how it all worked.<br>
<br>
First off, it desperately needs an &quot;executive summary&quot; section up=
 at the top.=C2=A0 There&#39;s a *lot* going on, and having a big-picture o=
verview would help a ton.=C2=A0 (For examples, see property hooks[1] and pa=
ttern matching[2].)=C2=A0 <br>
<br>
Second, please include realistic examples.=C2=A0 Nearly all of the examples=
 are contrived, which doesn&#39;t help me see how I would actually use asyn=
c routines or what the common patterns would be, and I therefore cannot eva=
luate how well the proposal treats those common cases.=C2=A0 The first non-=
foobar example includes a comment &quot;of course you should never do it li=
ke this&quot;, which makes the example rather useless.=C2=A0 And the second=
 is built around a code model that I would never, ever accept into a code b=
ase, so it&#39;s again unhelpful.=C2=A0 Most of the RFC also uses examples =
that... have no return values.=C2=A0 So from reading the first half of it, =
I honestly couldn&#39;t tell you how return values work, or if they&#39;re =
wrapped in a Future or something.<br>
<br>
Third, regarding syntax, I largely agree with Tim that keywords are better =
than functions.=C2=A0 This is very low-level functionality, so we can and s=
hould build dedicated syntax to make it as robust and self-evident (and IDE=
 friendly) as possible.<br>
<br>
That said, even allowing for the async or await or spawn keywords, I got su=
per confused when the Scope object was introduced.=C2=A0 So would the funct=
ions/keywords be shortcuts for some of the common functionality of a Scope =
object?=C2=A0 If not, what&#39;s the actual difference?=C2=A0 I got lost at=
 that point.<br>
<br>
The first few sections of the RFC seem to read as &quot;this RFC doesn&#39;=
t actually work at all, until some future RFC handles this other part.&quot=
;=C2=A0 Which... no, that&#39;s not how this works. :-)<br>
<br>
As someone that has not built an async framework before (which is 99.9% of =
PHP developers, including those on this list), I do not see the point of ha=
lf the functionality here.=C2=A0 Especially the BoundedScope.=C2=A0 I see n=
o reason for it to be separate from just any other Scope.=C2=A0 What is the=
 difference between scope and context?=C2=A0 I have no clue.=C2=A0 <br>
<br>
My biggest issue, though, is that I honestly can&#39;t tell what the mental=
 model is supposed to be.=C2=A0 The RFC goes into detail about three differ=
ent async models.=C2=A0 Are those standard terms you&#39;re borrowing from =
elsewhere, or your own creation?=C2=A0 If the former, please include citati=
ons.=C2=A0 I cannot really tell which one the &quot;playpen&quot; model wou=
ld fit into.=C2=A0 I... think bottom up, but I&#39;m not sure.=C2=A0 Moreov=
er, I then cannot tell which of those models is in use in the RFC.=C2=A0 Th=
ere&#39;s a passing reference to it being bottom up, I think, but it certai=
nly looks like the No Limit model.=C2=A0 There&#39;s a section called struc=
tured concurrency, but what it describes doesn&#39;t look a thing like the =
playpen-definition of structured concurrency, which as noted is my preferen=
ce.=C2=A0 It&#39;s not clear why the various positives and negatives are th=
ere; it&#39;s just presented as though self-evident.=C2=A0 Why does bottom =
up lead to high memory usage, for instance?=C2=A0 That&#39;s not clear to m=
e.=C2=A0 So really... I have no idea how to think about any of it.<br>
<br>
Sorry, I&#39;m just totally lost at this point.<br>
<br>
As an aside: I used &quot;spawn&quot; as a throw-away keyword to avoid usin=
g &quot;await&quot; in a previous example.=C2=A0 It&#39;s probably not the =
right word to use in most of these cases.<br>
<br>
I know some have expressed the sentiment that tightly structured concurrenc=
y is just us not trusting developers and babysitting them.=C2=A0 To which I=
 say... YES!=C2=A0 The overwhelming majority of PHP developers have no expe=
rience writing async code.=C2=A0 Their odds of getting it wrong and doing s=
omething inadvertently stupid by accident through not understanding some nu=
ance are high.=C2=A0 And I include myself in that.=C2=A0 MY chances of inad=
vertently doing something stupid by accident are high.=C2=A0 I *want* a des=
ign that doesn&#39;t let me shoot myself in the foot, or at least makes it =
difficult to do.=C2=A0 If that means I cannot do everything I want to... GO=
OD!=C2=A0 Humans are not to be trusted with manually coordinating paralleli=
sm.=C2=A0 We&#39;re just not very good at it, as a species.<br>
<br>
Broadly speaking, I can think of three usage patterns for async in PHP (spe=
aking, again, as someone who doesn&#39;t have a lot of async experience, so=
 I may be missing some):<br>
<br>
1. Fan-out.=C2=A0 This is the &quot;fetch all these URLs at once&quot; type=
 use case, which in most cases could be wrapped up into a para_map() functi=
on.=C2=A0 (Which is exactly what Rust does.)<br>
2. Request handlers, for persistent-process servers.=C2=A0 Would also apply=
 for a queue worker.<br>
3. Throw it over the wall.=C2=A0 This would be the logging example, or send=
ing an email on some trigger, etc.=C2=A0 Importantly, these are cases where=
 there is no result needed from the sub-routine.<br>
<br>
I feel like those three seem to capture most reasonable use cases, give or =
take some details.=C2=A0 (And, of course, many apps will include all three =
in various places.)=C2=A0 So any proposal should include copious examples o=
f how those three cases would look, and why they&#39;re sufficiently ergono=
mic.<br>
<br>
A playpen model can handle both 1 and 2.=C2=A0 In fan out, you want the &qu=
ot;Wait all&quot; logic, but then you also need to think about a Future obj=
ect or similar.=C2=A0 In a request handler, you&#39;re spawning an arbitrar=
y number of coroutines that will terminate, and you probably don&#39;t care=
 if they have a return value.<br>
<br>
It&#39;s the &quot;throw over the wall&quot; cases where a playpen takes mo=
re work.=C2=A0 As I showed previously, it can be done.=C2=A0 It just takes =
a bit more setup.=C2=A0 But if that is too much for folks, I offer a compro=
mise position.=C2=A0 Again, just spitballing the syntax specifics:<br>
<br>
// Creates an async scope, in which you can create coroutines.<br>
async {<br>
<br>
=C2=A0 // Creates a new coroutine that MAY last beyond the scope of this bl=
ock.<br>
=C2=A0 // However, it MUST be a void-return function, indicating that it=
9;s going to<br>
=C2=A0 // do work that is not relevant to the rest of this block.<br>
=C2=A0 spawn func_call(1, 2, 3);<br>
<br>
=C2=A0 // Creates a new coroutine that will block at the end of this async =
block.<br>
=C2=A0 // The return value is a future for whatever other_function() will r=
eturn.<br>
=C2=A0 // $future may be used as though it were the type returned, but tryi=
ng <br>
=C2=A0 // to read it will block until the function completes.=C2=A0 It may =
also have other<br>
=C2=A0 // methods on it, not sure.<br>
=C2=A0 $future =3D start other_function(4, 5, 6);<br>
<br>
=C2=A0 // Queues a coroutine to get called after all &quot;start&quot;ed co=
routines have completed<br>
=C2=A0 // and this block is about to end.=C2=A0 Its return value is discard=
ed. Perhaps it should be<br>
=C2=A0 // restricted to void-return, not sure.=C2=A0 In this case it doesn&=
#39;t hurt anything.<br>
=C2=A0 defer cleanup(7, 8, 9);<br>
<br>
=C2=A0 // Do nothing except allow other coroutines to switch in here if the=
y want.<br>
=C2=A0 suspend;<br>
<br>
=C2=A0 // Enqueues this coroutine to run in 100 ms, or slightly thereafter =
whenever the scheduler gets to it.<br>
=C2=A0 timeout 100ms something(4, 5, 6);<br>
<br>
} // There is an implicit wait-all here for anything start-ed, but not for =
spawn-ed.<br>
<br>
I honestly cannot see a use case at this point for starting coroutines in a=
rbitrary scopes.=C2=A0 Only &quot;current scope&quot; and &quot;global scop=
e, let it escape.&quot;=C2=A0 That maps to &quot;start&quot; and &quot;spaw=
n&quot; above.=C2=A0 If internally &quot;spawn&quot; gets translated to &qu=
ot;start in the implicit async block that is the entire application&quot;, =
so that those coroutines will still block the whole script from terminating=
, that is not a detail most devs will care about.=C2=A0 (Which also means i=
n the global async scope, spawn and start are basically synonymous.)<br>
<br>
I can see the need for cancellation, which means probably we do need a scop=
e object to represent the current async block.=C2=A0 However, that&#39;s ju=
st a cancel() method, which would propagate to any child.=C2=A0 Scheduling =
it can be handled by the timeout command.=C2=A0 At this point, I do not see=
 the use case for anything more advanced than the above (except for channel=
s, which as I argued before could make spawn unnecessary).=C2=A0 There may =
be a good reason for it, but I don&#39;t know what it is and the RFC does n=
ot make a compelling argument for why anything more is needed.<br>
<br>
I could see an argument that async $scope { ... } lets you call all of the =
above keywords as methods on $scope, and the keywords are essentially a sho=
rthand for &quot;this method on the current scope&quot;.=C2=A0 But you coul=
d also pass the scope object around to places if you want to do dangerous t=
hings.=C2=A0 I&#39;m not sure if I like that, honestly, but it seems like a=
n option.<br>
<br>
Elsewhere in the thread, Tim noted that we should unify the function call v=
s closure question.=C2=A0 I used straight function calls above for simplici=
ty, but standardizing on a closure also makes sense.=C2=A0 Related, I&#39;v=
e been talking with Arnaud about trying to put Partial Function Application=
 forward again[3], assuming pipes[4] pass.=C2=A0 If we follow the previous =
model, then it would implicitly provide a way to turn any function call int=
o a delayed function call:<br>
<br>
function foo(int $a, int $b) { ... }<br>
<br>
foo(4, 5); // Calls foo() right now<br>
foo(4, 5, ...); // Creates a 0-argument closure that will call foo(4, 5) wh=
en invoked.<br>
<br>
Basically the latter is equivalent to:<br>
fn() =3D&gt; foo(4, 5);<br>
<br>
A 0-argument closure (because all arguments are already captured) goes by t=
he delightful name &quot;thunk&quot; (as in the past tense of think, if you=
 don&#39;t know English very well.)=C2=A0 That likely wouldn&#39;t be ideal=
, but it would make standardizing start/spawn on &quot;thou shalt provide a=
 closure&quot; fairly straightforward, as any function could trivially be w=
rapped into one.<br>
<br>
That&#39;s not necessarily the best way, but I mention it to show that ther=
e are options available if we allow related features to support each other =
synergistically, which I always encourage.<br>
<br>
Like Tim, I applaud you&#39;re commitment to this topic and willingness to =
work with feedback.=C2=A0 But the RFC text is still a long way from a model=
 that I can wrap my head around, much less support.<br>
<br>
[1] <a href=3D"https://wiki.php.net/rfc/property-hooks" rel=3D"noreferrer" =
target=3D"_blank">https://wiki.php.net/rfc/property-hooks</a><br>
[2] <a href=3D"https://wiki.php.net/rfc/pattern-matching" rel=3D"noreferrer=
" target=3D"_blank">https://wiki.php.net/rfc/pattern-matching</a><br>
[3] <a href=3D"https://wiki.php.net/rfc/partial_function_application" rel=
=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/partial_function=
_application</a><br>
[4] <a href=3D"https://wiki.php.net/rfc/pipe-operator-v3" rel=3D"noreferrer=
" target=3D"_blank">https://wiki.php.net/rfc/pipe-operator-v3</a><br>
<br>
--Larry Garfield<br>
</blockquote></div>

--000000000000a4fb0f06309e20c1--