Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127133
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8BVd-dqcy7tabMEcOOLZPcqWj9o64tEVPepvHxcQ2BPzQ@mail.gmail.com>
 <EE188994-2384-4226-8C09-B786279C5998@rwec.co.uk> <CAMW7n8C+jtqeprvz_h8mXBw1mNp1ZrWrqNPoVpv6=H3Qc5H3iw@mail.gmail.com>
In-Reply-To: <CAMW7n8C+jtqeprvz_h8mXBw1mNp1ZrWrqNPoVpv6=H3Qc5H3iw@mail.gmail.com>
Date: Thu, 17 Apr 2025 12:18:49 +0100
Message-ID: <CAHXoPRuZ-oLDnW5pCVp8Y3qXMpgWUJLCD9478-OaZJGzqKQYhg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 3
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000beabfe0632f791a4"
From: oladoyinbov@gmail.com (Oladoyinbo Vincent)

--000000000000beabfe0632f791a4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Here are list of the problems i saw in this RFC:

1.) The `spawn` keyword might disqualify this rfc, i talked to alot of php
devs about this rfc and they all had a similar complaint about the keyword,
maybe a keyword choice poll might help when the rfc voting goes live.

2.) This whole rfc seem a little bit complex, which might ruin php codebase
readability, let's keep things simple and concise, first impression matters
for beginners and intermediate php programmers.

3.) Let's not derive impression from java at this point, PHP might look
similar to java but programmers hate java for a reason, overbloated way of
doing simple things.



On Thu, 17 Apr 2025, 9:55=E2=80=AFam Edmond Dantes, <edmond.ht@gmail.com> w=
rote:

> Hello, Rowan!
>
> > I don't have time to dig into the details of this draft at the moment,
> but will say that a vote in two weeks is not at all realistic.
> I just used the Flow from the Wiki. :)
>
> > My only other comment at a very quick glance is that I see the Context
> section is still included, and still has most of its complexity.
> Almost every section of the RFC has a "Motivation" subsection, which
> explains why a particular tool is needed and what problem it solves.
> I removed everything from the RFC that is not directly related to
> asynchrony or not essential at this stage.
>
> Yesterday I also received feedback that the RFC contains too many changes=
,
> so I can briefly summarize what=E2=80=99s new in this version compared to=
 the
> previous one:
>
>    1.
>
>    The Scope class can no longer be used in an await expression. A
>    separate method is now provided for waiting on a Scope, intended only =
for
>    special use cases.
>    2.
>
>    Scope is now responsible solely for coroutine lifetime and error
>    handling.
>    3.
>
>    A TaskGroup class has been added for working with groups of tasks. It
>    is used explicitly with the expression spawn with $taskGroup. Together
>    with Scope, TaskGroup supports structured concurrency, offering
>    different strategies for tracking hanging coroutines.
>
> *These are the key changes.*
>
> *Secondary changes include:*
>
>    1.
>
>    Syntax refinement
>    2.
>
>    Edge case handling
>    3.
>
>    Ability to extend spawn with logic
>    4.
>
>    Added combinator functions: all, any, anyOf, ignoreErrors
>    5.
>
>    A special function Async\protect() has been added for critical
>    sections that cannot be cancelled.
>    6.
>
>    Improved examples
>
> Contextual expressions like with $context and async blocks were removed
> from the RFC as they are out of its scope.
>
> The next important step is to determine which coroutine model to choose.
> There are three models in total:
>
>    1.
>
>    Go =E2=80=93 no Scope
>    2.
>
>    Java Loom =E2=80=93 Scope is always passed explicitly
>    3.
>
>    The current RFC =E2=80=93 Scope is passed both explicitly and implicit=
ly
>
> The choice of model affects both the syntax and the API. Therefore, if th=
e
> current model is not accepted, there is no point in further developing th=
is
> RFC =E2=80=94 a new one should be created instead.
>
> This is the key question I want to clarify at this stage.
>
> --
>
> Ed
>

--000000000000beabfe0632f791a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Here are list of the problems i saw in =
this RFC:</div><div dir=3D"auto"><br></div>1.) The `spawn` keyword might di=
squalify this rfc, i talked to alot of php devs about this rfc and they all=
 had a similar complaint about the keyword, maybe a keyword choice poll mig=
ht help when the rfc voting goes live.<div dir=3D"auto"><br></div><div dir=
=3D"auto">2.) This whole rfc seem a little bit complex, which might ruin ph=
p codebase readability, let&#39;s keep things simple and concise, first imp=
ression matters for beginners and intermediate php programmers.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">3.) Let&#39;s not derive impression=
 from java at this point, PHP might look similar to java but programmers ha=
te java for a reason, overbloated way of doing simple things.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 17 Apr 2025, 9:55=
=E2=80=AFam Edmond Dantes, &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmon=
d.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>Hello, Rowan!</div><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">&gt; I don&#39;t have time to dig into the details of this draft at th=
e moment, but will say that a vote in two weeks is not at all realistic.<br=
>I just used the Flow from the Wiki. :)</div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr">&gt; My only other comment at a very quick glance is that I s=
ee the Context section is still included, and still has most of its complex=
ity.</div><div dir=3D"ltr">Almost every section of the RFC has a &quot;Moti=
vation&quot; subsection, which explains why a particular tool is needed and=
 what problem it solves.=C2=A0</div><div dir=3D"ltr">I removed everything f=
rom the RFC that is not directly related to asynchrony or not essential at =
this stage.=C2=A0=C2=A0</div><div class=3D"gmail_quote"><div><br></div><p>Y=
esterday I also received feedback that the RFC contains too many changes, s=
o I can briefly summarize what=E2=80=99s new in this version compared to th=
e previous one:</p>
<ol>
<li>
<p>The <code>Scope</code> class can no longer be used in an <code>await</co=
de> expression. A separate method is now provided for waiting on a Scope, i=
ntended only for special use cases.</p>
</li>
<li>
<p><code>Scope</code> is now responsible solely for coroutine lifetime and =
error handling.</p>
</li>
<li>
<p>A <code>TaskGroup</code> class has been added for working with groups of=
 tasks. It is used explicitly with the expression <code>spawn with $taskGro=
up</code>. Together with <code>Scope</code>, <code>TaskGroup</code> support=
s structured concurrency, offering different strategies for tracking hangin=
g coroutines.</p>
</li>
</ol>
<p><strong>These are the key changes.</strong><strong><br></strong></p><p><=
strong>Secondary changes include:</strong></p>
<ol>
<li>
<p>Syntax refinement</p>
</li>
<li>
<p>Edge case handling</p>
</li>
<li>
<p>Ability to extend <code>spawn with</code> logic</p>
</li>
<li>
<p>Added combinator functions: <code>all</code>, <code>any, anyOf, ignoreEr=
rors</code></p>
</li><li><p>A special function Async\protect() has been added for critical =
sections that cannot be cancelled.=C2=A0=C2=A0</p></li>
<li>
<p>Improved examples</p>
</li>
</ol>
<div>Contextual expressions like <code>with $context</code> and <code>async=
</code> blocks were removed from the RFC as they are out of its scope.=C2=
=A0</div><div><br></div><div>The next important step is to determine which =
coroutine model to choose. There are three models in total:</div><div>
<ol>
<li>
<p>Go =E2=80=93 no Scope</p>
</li>
<li>
<p>Java Loom =E2=80=93 Scope is always passed explicitly</p>
</li>
<li>
<p>The current RFC =E2=80=93 Scope is passed both explicitly and implicitly=
</p>
</li>
</ol>
<p>The choice of model affects both the syntax and the API. Therefore, if t=
he current model is not accepted, there is no point in further developing t=
his RFC =E2=80=94 a new one should be created instead.</p><p>This is the ke=
y question I want to clarify at this stage.=C2=A0=C2=A0</p><p>--</p><p>Ed</=
p></div></div></div>
</blockquote></div>

--000000000000beabfe0632f791a4--