On Sat, Mar 1, 2025, at 10: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
>
> I believe this version is not perfect and requires analysis. And I st
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
I believe this version is not perfect and requires analysis. And I strongly
believe that things like this shouldn't be developed in iso
So to summarize the proposed behavior (as I understand it):
* If an enum is backed, it auto-casts to ->value
* If an enum is not backed, it auto-casts to ->name
I believe this has the following problems (at least):
* Unbacked enums are not supposed to be representable as scalar values -
if I,
>
> FYI: once you introduce a draft RFC for discussion, the RFC should change
> status to "under discussion" per (4):
>
>
It's done. Thank you.
Ed.
On 1 Mar 2025, at 08:37, Rob Landers wrote:
>
> Hi Alwin,
>
> You may be interested in http://wiki.php.net/rfc/records, whose goal from the
> beginning was a new type that behaved like arrays (value semantics, copy on
> write) as well as the ability to attach behavior to them.
>
> I’ve since
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 thing
On Sat, Mar 1, 2025, at 18:20, Rowan Tommins [IMSoP] wrote:
> 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
> >
>
> 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.
>
> Thank you for the kind words, it was awesome to read.
I wonder if there are ways it can be split into smaller pieces, so that
> we don't overl
> but it would be interesting to replace the scheduler with something that
> utilized go-routines for true multi-threading. Whether that works or not,
> is a whole different can of worms.
>
> — Rob
>
If the question is whether it is possible to interact with a PHP thread
from another thread by send
