On 01/03/2025 09:11, Edmond Dantes wrote:
Good day, everyone. I hope you're doing well.
I’d like to introduce a draft version of the RFC for the True Async
component.
https://wiki.php.net/rfc/true_async
My reaction to this can be summed up as "this is huge!" By that I mean
multiple things...
First: PHP having native async support would be a huge step forward for
the language. It's really exciting to see how this proposal develops.
Second: it's clear you've put a huge amount of work into this, so a huge
thank you for that, and I hope it is rewarded.
Third: this is a huge proposal to digest. I wonder if there are ways it
can be split into smaller pieces, so that we don't overlook details in
one part because our focus is drawn to another. That might mean
releasing a partial implementation this year, and more features next
year; or it might just mean discussing and merging some core pieces
first, then immediately following up with a series of feature RFCs, all
targeting the same release.
Fourth: design decisions here will have a huge impact on the language
for years to come. We should spend plenty of time looking at experience
from elsewhere - other languages, and existing third-party async
implementations for PHP. This is closely related to the previous point,
since expanding the current RFC with comparisons for every decision
would make it impractically long.
Fifth: this is a huge amount of new code - GitHub says 24 thousand lines
of added code, although some of that is tests and documentation (which
is great to see included!) We need to make sure there are enough people
who understand the implementation to maintain that. Maybe we can try to
tempt some of the core contributors to existing third-party libraries to
spend some of their time on php-src instead.
I realise I haven't actually given any concrete feedback on the proposal
- I don't have any experience with other async implementations, and
don't fully understand the concepts involved, so don't feel qualified to
comment on the high-level design questions. I might have opinions on
smaller design details (random example: RESOLVE, CANCEL, and TIMEOUT
should be cases on an enum, not int constants) but see point 4: there's
just too much here to discuss in that level of detail, and there are
top-level decisions which should be our focus first.
To re-iterate: this is really exciting, and thanks for getting it to
this stage!
--
Rowan Tommins
[IMSoP]
