Hi > But that is separate from the question of whether it's possible to build on > Fibers, rather than effectively deprecate them in practice if not in name.
Originally, Fiber was proposed with a Scheduler, but the Scheduler was refused. To allow Fiber switching without a Scheduler, they were made **symmetric** (so that the switching code could do it manually). This, in turn, creates a problem when trying to add a Scheduler later. To create coroutines, you need to write the "switching code". But to write the switching code, Fibers must be allowed to switch arbitrarily. And for Fibers to switch arbitrarily, backward compatibility must be broken. What could be reused? The context-switching code and the observer component handlers — these were reused. The issue isn’t that Fiber behavior can’t be changed, but that it should be **hidden as an internal component**. There should be **no access to it from PHP code**. The experience with Fiber shows that language features like asynchrony must be **designed as a whole from the start** — thoughtfully and consistently. You can’t make a language "a little" asynchronous today and a bit "more" tomorrow: 1. Critical components must be designed **in advance** to understand how they interact. 2. They must be placed within the **same layer of abstraction**. 3. Use cases must be thought out in advance. --- Best regards Ed
