Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129264
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> <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>
In-Reply-To: <CAMW7n8ARHDQUeVKzsd44a11WGSuRm9CpvVK_D9YnBtMp9VxBSw@mail.gmail.com>
Date: Sun, 16 Nov 2025 11:46:11 +0100
Message-ID: <CAEKnhAEAFHK60b_Gg-hAHoXxR=gRb+72=oDKAwG-nUvK9_rV7Q@mail.gmail.com>
Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5)
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, Michael Morris <tendoaki@gmail.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000117b900643b3f1c3"
From: bukka@php.net (Jakub Zelenka)

--000000000000117b900643b3f1c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Nov 16, 2025 at 7:58=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.com>=
 wrote:

> Hello
>
> > Maybe that=E2=80=99s inherent to a subject matter that indeed could be =
the
> biggest change to PHP since 7,
> > but given RFC voting history, all signs point to a rejection vote.
>
> I think so too.
>
>
It looks like it but it's hard to say because many people have not had
chance to review / comment on this. I think it needs more time and the RFC
text needs more work to explain the basic difference.  I think it also need
to have a good implementation for what is being proposed to have any chance
because there are often voters that will vote down just because there is no
implementation that can be reviewed. Basically everything that can be
addressed should be addressed before the vote so it's just decisions
between the actual approach.


> > I don=E2=80=99t know how much has been discussed off list and/or how ma=
ny voters
> are involved off list.
>
> There were almost no discussions apart from the one on INTERNALS. I
> mean, there were no discussions that I=E2=80=99m aware of.
>
> I don=E2=80=99t know what to do about a situation where PHP developers ar=
e
> 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 wo=
rth discussing at
> all.
>

I think this is more that some people clearly prefer coloring and want to
point out the potential issues with this approach. This might be quite hard
to overcome and depends how many voters have such preference. Personally I
agree that coloring would be bad for PHP as I was dealing with "coloring
migration" in Python and it wasn't nice. That's why I think it might help
to have dedicated section about coloring (more comparison with the current
approach) in the RFC.

Kind regards,

Jakub

--000000000000117b900643b3f1c3
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 7:58=
=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; Maybe that=E2=80=99s inherent to a subject matter that indeed could be=
 the biggest change to PHP since 7,<br>
&gt; but given RFC voting history, all signs point to a rejection vote.<br>
<br>
I think so too.<br>
<br></blockquote><div><br></div><div>It looks like it but it&#39;s hard to =
say because many people have not had chance to review / comment on this. I =
think it needs more time and the RFC text needs more work to explain the ba=
sic difference.=C2=A0 I think it also need to have a good implementation fo=
r what is being proposed to have any chance because there are often voters =
that will vote down just because there is no implementation that can be rev=
iewed. Basically everything that can be addressed should be addressed befor=
e the vote so it&#39;s just decisions between the actual approach.</div><di=
v>=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; I don=E2=80=99t know how much has been discussed off list and/or how m=
any voters are involved off list.<br>
<br>
There were almost no discussions apart from the one on INTERNALS. I<br>
mean, there were no discussions that I=E2=80=99m aware of.<br>
<br>
I don=E2=80=99t know what to do about a situation where PHP developers are<=
br>
surprised to learn that their language has supported transparent<br>
asynchrony as a core paradigm for several years already.<br>
And instead of discussing the important details of the RFC, all the<br>
effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t wort=
h discussing at<br>
all.<br></blockquote><div><br></div><div>I think this is more that some peo=
ple clearly prefer coloring and want to point out the potential issues with=
 this approach. This might be quite hard to overcome and depends how many v=
oters have such preference. Personally I agree that coloring would be bad f=
or PHP as I was dealing with &quot;coloring migration&quot; in Python and i=
t wasn&#39;t nice. That&#39;s why I think it might help to have dedicated s=
ection about coloring (more comparison with the current approach) in the RF=
C.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Jakub</d=
iv></div></div>

--000000000000117b900643b3f1c3--