Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129250
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@mail.gmail.com>
 <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <CAMW7n8AX7O7x99KGdPSai6sPP1Xd6V4ojQ7CEWmxthNLPM2hyQ@mail.gmail.com>
 <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com> <CAEKnhAHp9fCOD0NCLE9J25dTkVd72csHGb3HGwATg+qyxNaFwg@mail.gmail.com>
 <41c5eed0-dd1b-4ea4-99cf-f6d16682bd7f@app.fastmail.com> <CAEKnhAEmSZn=Tr24YC9wxAUk1NPM529GR_iBWmX=fKpXxpuXRg@mail.gmail.com>
 <f777dba4-b29f-4744-889e-131ec730e305@app.fastmail.com> <CAMW7n8AovFXC6by4AyAwh0U9Gax2UQ-MkkpwqCPkP8hNz52hew@mail.gmail.com>
In-Reply-To: <CAMW7n8AovFXC6by4AyAwh0U9Gax2UQ-MkkpwqCPkP8hNz52hew@mail.gmail.com>
Date: Sat, 15 Nov 2025 23:36:49 +0100
Message-ID: <CAEKnhAHe9ToAH8tMppPSWG7j-1R+ho6Kf49HqSVXesnCX1_Cog@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Rob Landers <rob@bottled.codes>, php internals <internals@lists.php.net>, 
	Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary="000000000000a411670643a9c076"
From: bukka@php.net (Jakub Zelenka)

--000000000000a411670643a9c076
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 15, 2025 at 11:06=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com=
> wrote:

> > I guess my main thing is that this RFC should only cover coroutine
> machinery: it should not promise "transparent async" or "code
>
> It=E2=80=99s like trying to dig a hole with half a shovel :)
>
>
I think Rob has got a point that you don't really need to give such
promises that lack on details.


> > that works exactly the same" OR if it wants to make those claims, it
> should actually demonstrate
> > how instead of hand-waving everything as an "implementation detail" whe=
n
> none of those claims can actually be validated without those details.
>
> All of my claims are backed by tests :)
>

The problem is that no tests are really provided with the RFC in the PR
that can be easily checked. I think it's kind of a problem of all RFC's
that don't have implementation (this one have but it's really hard to
extract). The people can only guess your intention but cannot really verify
them as they could if there was implementation.

Kind regards,

Jakub

--000000000000a411670643a9c076
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Nov 15, 2025 at 11:06=E2=80=AFPM =
Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond.ht@gmail.co=
m</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">&gt; I guess my main thing is=
 that this RFC should only cover coroutine machinery: it should not promise=
 &quot;transparent async&quot; or &quot;code<br>
<br>
It=E2=80=99s like trying to dig a hole with half a shovel :)<br>
<br></blockquote><div><br></div><div>I think Rob has got a point that you d=
on&#39;t really need to give such promises that lack on details.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; that works exactly the same&quot; OR if it wants to make those claims,=
 it should actually demonstrate<br>
&gt; how instead of hand-waving everything as an &quot;implementation detai=
l&quot; when none of those claims can actually be validated without those d=
etails.<br>
<br>
All of my claims are backed by tests :)<br></blockquote><div><br></div><div=
>The problem is that no tests are really provided with the RFC in the PR th=
at can be easily checked. I think it&#39;s kind of a problem of all RFC&#39=
;s that don&#39;t have implementation (this one have but it&#39;s really ha=
rd to extract). The people can only guess your intention but cannot really =
verify them as they could if there was implementation.</div><div><br></div>=
<div>Kind regards,</div><div><br></div><div>Jakub</div></div></div>

--000000000000a411670643a9c076--