Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129262
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>
 <CAEKnhAHe9ToAH8tMppPSWG7j-1R+ho6Kf49HqSVXesnCX1_Cog@mail.gmail.com> <CAMW7n8BOo+qAi4P8TcPnyDTtZJ+vedDUL9LMWdoEaaTTj=KCmw@mail.gmail.com>
In-Reply-To: <CAMW7n8BOo+qAi4P8TcPnyDTtZJ+vedDUL9LMWdoEaaTTj=KCmw@mail.gmail.com>
Date: Sun, 16 Nov 2025 11:28:51 +0100
Message-ID: <CAEKnhAH_i1O=5aAdasM11KC2aMJUXUHLL=MKdBE+3H8kMsCbvQ@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="0000000000001aa1c00643b3b333"
From: bukka@php.net (Jakub Zelenka)

--0000000000001aa1c00643b3b333
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Nov 16, 2025 at 5:22=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.com>=
 wrote:

> Hello.
>
> > I think Rob has got a point that you don't really need to give such
> promises that lack on details.
> The problem is that the phrase from the RFC is being interpreted in a
> distorted way, and meaning is being attributed to it that it never
> had. Not to mention the fact that real-world facts are being ignored.
>
>
Well I can see why this phrases are confusing for some users. The thing is
that saying that something will behave exactly the same omits the fact that
it introduces the new suspension points that can have side effects. This
might be clear to you but I can see why it's not clear to others. I think
this is really more wording issue and you should make it clearer or not to
claim it at all.

I think what could help is to also add a section comparing the coloring
approach and why you think this is a better for PHP.


> > 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.
>
> This RFC has more than 300 tests that you can review. They=E2=80=99re als=
o
> sorted into folders, have descriptions, and are quite easy to read.
> There are also two Dockerfiles for this RFC that let you run PHP 8.6
> and try all the features with a single command.
>

But that's in your php-src branch + extension code so it's very hard for
everyone to find and even harder to try. My argument was that this should
be extracted in the minimal form to the PR so people can see what's being
proposed and don't need to guess based on the RFC content.

Kind regards,

Jakub

--0000000000001aa1c00643b3b333
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Nov 16, 2025 at 5:22=
=E2=80=AFAM Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond=
.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Hello.<br>
<br>
&gt; I think Rob has got a point that you don&#39;t really need to give suc=
h promises that lack on details.<br>
The problem is that the phrase from the RFC is being interpreted in a<br>
distorted way, and meaning is being attributed to it that it never<br>
had. Not to mention the fact that real-world facts are being ignored.<br>
<br></blockquote><div><br></div><div>Well I can see why this phrases are co=
nfusing for some users. The thing is that saying that something will behave=
 exactly the same omits the fact that it introduces the new suspension poin=
ts that can have side effects. This might be clear to you but I can see why=
 it&#39;s not clear to others. I think this is really more wording issue an=
d you should make it clearer or not to claim it at all.</div><div><br></div=
><div>I think what could help is to also add a section comparing the colori=
ng approach and why you think this is a better for PHP.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; The problem is that no tests are really provided with the RFC in the P=
R that can be easily checked.<br>
&gt; I think it&#39;s kind of a problem of all RFC&#39;s that don&#39;t hav=
e implementation (this one have but it&#39;s really hard to extract).<br>
&gt; The people can only guess your intention but cannot really verify them=
 as they could if there was implementation.<br>
<br>
This RFC has more than 300 tests that you can review. They=E2=80=99re also<=
br>
sorted into folders, have descriptions, and are quite easy to read.<br>
There are also two Dockerfiles for this RFC that let you run PHP 8.6<br>
and try all the features with a single command.<br></blockquote><div><br></=
div><div>But that&#39;s in your php-src branch=C2=A0+ extension code so it&=
#39;s very hard for everyone to find and even harder to try. My argument wa=
s that this should be extracted in the minimal form to the PR so people can=
 see what&#39;s being proposed and don&#39;t need to guess based on the RFC=
 content.</div><div><br></div><div>Kind regards,</div><div><br></div><div>J=
akub</div></div></div>

--0000000000001aa1c00643b3b333--