Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126602
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com> <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <54736CFE-DDCB-46A3-88A0-CFED30ED2CAA@daniil.it>
In-Reply-To: <54736CFE-DDCB-46A3-88A0-CFED30ED2CAA@daniil.it>
Date: Thu, 6 Mar 2025 14:18:56 +0200
Message-ID: <CAMW7n8CVMdN0y3F83__-7eGS3nCcmbmNVtFmodN=XmBR=t8+Nw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Daniil Gentili <daniil@daniil.it>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000039b073062fab830c"
From: edmond.ht@gmail.com (Edmond Dantes)

--00000000000039b073062fab830c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello, Daniil.

> Essentially, the only thing that=E2=80=99s needed for backwards-compatibi=
lity in
most cases is an API that can be used to register onWritable,
> onReadable callbacks for streams and a way to register delayed (delay)
tasks, to completely remove the need to invoke stream_select.

Thank you for this point. It seems I was mistaken in thinking that there is
a Scheduler inside Revolt. Of course, if we're only talking about the
EventLoop, maintaining compatibility won't be an issue at all.

> I=E2=80=99d recommend chatting with Aaron to further discuss backwards
compatibility and the overall RFC: I=E2=80=99ve already pinged him, he=E2=
=80=99ll chime in
once he has more time to read the RFC.

That would be really cool.

> To Edmond, as someone who submitted RFCs before: stand your ground, try
not to listen too much to what people propose in this list,
> especially if it=E2=80=99s regarding radical changes like Larry's; avoid =
bloating
the RFC with proposals that you do not really agree with.

Actually, I agree in many ways. In programming, there's an eternal struggle
between abstraction and implementation,

between strict rules and flexibility, between paternalism where the
language makes decisions for you and freedom.

Each of these traits is beneficial in certain scenarios. The most important
thing is to understand whether it will be beneficial for PHP scenarios.
This is the main goal of this RFC stage. That's why I would really like to
hear the voices of those who create PHP's code infrastructure. I mean,
Symfony, Laravel, etc.

Thanks!

Ed.

--00000000000039b073062fab830c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello, Daniil.</div><div><br></div><div>&gt; Essentia=
lly, the only thing that=E2=80=99s needed for backwards-compatibility in mo=
st cases is an API that can be used to register onWritable, <br>&gt; onRead=
able callbacks for streams and a way to register delayed (delay) tasks, to =
completely remove the need to invoke stream_select.<br><br></div><div>Thank=
 you for this point. It seems I was mistaken in thinking that there is a Sc=
heduler inside Revolt. Of course, if we&#39;re only talking about the Event=
Loop, maintaining compatibility won&#39;t be an issue at all.</div><div>=C2=
=A0=C2=A0</div><div>&gt; I=E2=80=99d recommend chatting with Aaron to furth=
er discuss backwards compatibility and the overall RFC: I=E2=80=99ve alread=
y pinged him, he=E2=80=99ll chime in once he has more time to read the RFC.=
<br><br>That would be really cool.=C2=A0=C2=A0</div><div><br></div><div>&gt=
; To Edmond, as someone who submitted RFCs before: stand your ground, try n=
ot to listen too much to what people propose in this list, <br>&gt; especia=
lly if it=E2=80=99s regarding radical changes like Larry&#39;s; avoid bloat=
ing the RFC with proposals that you do not really agree with.</div><div><br=
></div><div><p>Actually, I agree in many ways. In programming, there&#39;s =
an eternal struggle between abstraction and implementation,=C2=A0</p><p>bet=
ween strict rules and flexibility, between paternalism where the language m=
akes decisions for you and freedom.</p><p>Each of these traits is beneficia=
l in certain scenarios. The most important thing is to understand whether i=
t will be beneficial for PHP scenarios. This is the main goal of this RFC s=
tage. That&#39;s why I would really like to hear the voices of those who cr=
eate PHP&#39;s code infrastructure. I mean, Symfony, Laravel, etc.</p><p>Th=
anks!</p><p>Ed.</p></div></div>

--00000000000039b073062fab830c--