> In my opinion, colored functions is the worst thing that could happen to PHP.
>
> https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function
> Describes quite expressively what's wrong about this approach.
>
> This is going to be a ton of changes, when currently sync (blue function) will have to become
> async (red one).
>
> The way amphp goes - it's the right way. They have had this problem of red-blue functions
> a long ago until Fibers came into place.
>
>
> This is just annoying, and IMO should not be considered.
+++++ on this, the discussion on this RFC is veering in a very annoying direction for absolutely no
good reason.
Golang has shown and proven that we do not need colored functions to make use of (extremely simple
to use) concurrency.
Please do not cripple the adoption of async php by making it colored and by adding absolutely
useless async blocks, forcing everyone to rewrite their codebases for absolutely no *good* reason,
when with the current colorless, fiber approach the only thing that's needed to adapt current
codebases for async is the usage of channels and a few appropriately placed synchronization
primitives (I know this from experience, migrating a large and complex codebase to be fully async).
The only thing that's truly needed in this RFC is a set of synchronization primitives like in
golang, and a way to parent/unparent fibers in order to inherit cancellations (as previously
mentioned in this list), not contexts, async blocks and colored functions.
Any issue around $_GET/etc superglobals (i.e. to handle each incoming request in a separate fiber)
should be solved at the SAPI level with a separate RFC, not by introducing contexts and async blocks
and making concurrency harder to use.
I like and use immutability, but it has it limits, it should not be used everywhere, and it should
not be forced upon everyone just because someone is a strong proponent of it.
Regards,
Daniil Gentili.