Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129261
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 16 Nov 2025 10:50:57 +0100
To: "Edmond Dantes" <edmond.ht@gmail.com>,
 =?UTF-8?Q?Marco_Aur=C3=A9lio_Deleu?= <deleugyn@gmail.com>
Cc: "Michael Morris" <tendoaki@gmail.com>,
 "php internals" <internals@lists.php.net>
Message-ID: <bc6b6fe4-0ede-4e34-b7b7-c14c32c3963b@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8ARHDQUeVKzsd44a11WGSuRm9CpvVK_D9YnBtMp9VxBSw@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>
 <CAMW7n8D3Mq6PveYxvfx=Djx6GnpkECOsEsEc2yKtJACAkAoLpQ@mail.gmail.com>
 <D0376B5C-7054-4948-BC48-5257F57B6129@zort.net>
 <CAEUnE0fcNP+R+r6rrMtUXcOYeCkutQzo-fTbkFpdL3VyLVXvQw@mail.gmail.com>
 <CADK1yXKS84aP9m=oExvL=rz2quGvXWKcPkV1h6gQj8vQUJjX3w@mail.gmail.com>
 <CAMW7n8ARHDQUeVKzsd44a11WGSuRm9CpvVK_D9YnBtMp9VxBSw@mail.gmail.com>
Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5)
Content-Type: multipart/alternative;
 boundary=f2d8771721184acba10af43f69281812
From: rob@bottled.codes ("Rob Landers")

--f2d8771721184acba10af43f69281812
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 16, 2025, at 07:56, Edmond Dantes wrote:
> Hello
[snip]
> I don=E2=80=99t know what to do about a situation where PHP developers=
 are
> surprised to learn that their language has supported transparent
> asynchrony as a core paradigm for several years already.
> And instead of discussing the important details of the RFC, all the
> effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t=
 worth discussing at
> all.
>=20
> It would be wonderful if there were a dedicated person whom everyone
> would listen to carefully and who could explain the basic questions
> privately. Most likely, this approach would solve many problems.

You are that person in this context.

RFC authors are the subject-matter experts for their proposals, and the =
way the process succeeds is by the author being willing to explain, rest=
ate, clarify, and anchor concepts for people coming from different backg=
rounds and different levels of familiarity. That sometimes means answeri=
ng questions that feel =E2=80=9Cbasic=E2=80=9D, or repeating an explanat=
ion with more context, or linking back to previous messages so readers c=
an follow the chain of reasoning.

Speaking personally: I=E2=80=99ve put several hours into each of my resp=
onses because I want the RFC to succeed, and I think many others on the =
list are doing the same. When people ask questions or point out tension =
between claims, it=E2=80=99s not to nitpick: it=E2=80=99s because the RF=
C makes several strong promises, and people want to understand the impli=
cations for their frameworks, their libraries, and their day-to-day work.

That=E2=80=99s exactly what the =E2=80=9CC=E2=80=9D in RFC is for.

If something has been explained earlier, linking to that explanation is =
extremely helpful. If something hasn=E2=80=99t been explained yet, then =
the question isn=E2=80=99t trivial, it=E2=80=99s a signal that the docum=
ent might need clearer wording so that future readers won=E2=80=99t have=
 the same confusion. It=E2=80=99s like a bug report: just because one us=
er reported the bug doesn=E2=80=99t mean only one person is suffering fr=
om it.

Everyone here is trying to understand the proposal on its own terms. Cle=
ar, patient communication from the author is what makes that possible.

=E2=80=94 Rob
--f2d8771721184acba10af43f69281812
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sun, Nov =
16, 2025, at 07:56, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Hello</div></blockquote><div>[snip]</div><bloc=
kquote type=3D"cite" id=3D"qt" style=3D""><div>I don=E2=80=99t know what=
 to do about a situation where PHP developers are</div><div>surprised to=
 learn that their language has supported transparent</div><div>asynchron=
y as a core paradigm for several years already.</div><div>And instead of=
 discussing the important details of the RFC, all the</div><div>effort g=
oes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t worth dis=
cussing at</div><div>all.<br></div><div><br></div><div>It would be wonde=
rful if there were a dedicated person whom everyone</div><div>would list=
en to carefully and who could explain the basic questions</div><div>priv=
ately. Most likely, this approach would solve many problems.</div></bloc=
kquote><div><br></div><div>You are that person in this context.</div><di=
v><br></div><div>RFC authors are the subject-matter experts for their pr=
oposals, and the way the process succeeds is by the author being willing=
 to explain, restate, clarify, and anchor concepts for people coming fro=
m different backgrounds and different levels of familiarity. That someti=
mes means answering questions that feel =E2=80=9Cbasic=E2=80=9D, or repe=
ating an explanation with more context, or linking back to previous mess=
ages so readers can follow the chain of reasoning.</div><div><br></div><=
div>Speaking personally: I=E2=80=99ve put several hours into each of my =
responses because I want the RFC to succeed, and I think many others on =
the list are doing the same. When people ask questions or point out tens=
ion between claims, it=E2=80=99s not to nitpick: it=E2=80=99s because th=
e RFC makes several strong promises, and people want to understand the i=
mplications for their frameworks, their libraries, and their day-to-day =
work.</div><div><br></div><div>That=E2=80=99s exactly what the =E2=80=9C=
C=E2=80=9D in RFC is for.</div><div><br></div><div>If something has been=
 explained earlier, linking to that explanation is extremely helpful. If=
 something hasn=E2=80=99t been explained yet, then the question isn=E2=80=
=99t trivial, it=E2=80=99s a signal that the document might need clearer=
 wording so that future readers won=E2=80=99t have the same confusion. I=
t=E2=80=99s like a bug report: just because one user reported the bug do=
esn=E2=80=99t mean only one person is suffering from it.</div><div><br><=
/div><div>Everyone here is trying to understand the proposal on its own =
terms. Clear, patient communication from the author is what makes that p=
ossible.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div=
></body></html>
--f2d8771721184acba10af43f69281812--