> 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. (Resent again as the other email has deliverability issues on the list).
