Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129263
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 16 Nov 2025 11:44:25 +0100
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Jakub Zelenka" <bukka@php.net>,
 "php internals" <internals@lists.php.net>,
 "Larry Garfield" <larry@garfieldtech.com>
Message-ID: <08303459-b4ab-44a8-9795-0fb7f82914d0@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8AovFXC6by4AyAwh0U9Gax2UQ-MkkpwqCPkP8hNz52hew@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
Content-Type: multipart/alternative;
 boundary=2a672d412dbd43988418b3479a2a7992
From: rob@bottled.codes ("Rob Landers")

--2a672d412dbd43988418b3479a2a7992
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 15, 2025, at 23:06, Edmond Dantes wrote:
> > I guess my main thing is that this RFC should only cover coroutine m=
achinery: it should not promise "transparent async" or "code
>=20
> It=E2=80=99s like trying to dig a hole with half a shovel :)
>=20
> > 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" =
when none of those claims can actually be validated without those detail=
s.
>=20
> All of my claims are backed by tests :)

I will leave with some final advice. The problem with tests is that they=
 only validate the current implementation, which isn=E2=80=99t guarantee=
d to be the final implementation. I would recommend reviewing your tests=
 and matching up each of them to where you mention that behavior or defi=
ne it in the RFC. If the tests are implementation-specific, then it need=
s to be defined in the RFC. For example, you say that the scheduler is 1=
00% an implementation detail, but your outputs in the tests rely on a sp=
ecific ordered queue. You should at least define the ordering the queue =
should be processed in the RFC (LIFO vs FIFO) so that even if the implem=
entation changes, the tests still pass.

That=E2=80=99s one example, you can review my previous comments to disco=
ver other examples, such as defining the rules of suspension points.

I wish you the best,

=E2=80=94 Rob
--2a672d412dbd43988418b3479a2a7992
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sat, Nov =
15, 2025, at 23:06, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; I guess my main thing is that this RFC sh=
ould only cover coroutine machinery: it should not promise "transparent =
async" or "code</div><div><br></div><div>It=E2=80=99s like trying to dig=
 a hole with half a shovel :)</div><div><br></div><div>&gt; that works e=
xactly the same" OR if it wants to make those claims, it should actually=
 demonstrate</div><div>&gt; how instead of hand-waving everything as an =
"implementation detail" when none of those claims can actually be valida=
ted without those details.</div><div><br></div><div>All of my claims are=
 backed by tests :)<br></div></blockquote><div><br></div><div>I will lea=
ve with some final advice. The problem with tests is that they only vali=
date the current implementation, which isn=E2=80=99t guaranteed to be th=
e final implementation. I would recommend reviewing your tests and match=
ing up each of them to where you mention that behavior or define it in t=
he RFC. If the tests are implementation-specific, then it needs to be de=
fined in the RFC. For example, you say that the scheduler is 100% an imp=
lementation detail, but your outputs in the tests rely on a specific ord=
ered queue. You should at least define the ordering the queue should be =
processed in the RFC (LIFO vs FIFO) so that even if the implementation c=
hanges, the tests still pass.</div><div><br></div><div>That=E2=80=99s on=
e example, you can review my previous comments to discover other example=
s, such as defining the rules of suspension points.</div><div><br></div>=
<div>I wish you the best,</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--2a672d412dbd43988418b3479a2a7992--