Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129047
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <2441aa9c-41c8-4ce1-b9c0-67136e5f97da@dennis.birkholz.biz>
 <CAMW7n8A6A-61Q1dzvQxhud0WYQdOKdANqmRbgNg2o=-Qyg5snA@mail.gmail.com> <3f8ebb9e-5329-47a1-8284-9c5f8cfe9308@app.fastmail.com>
In-Reply-To: <3f8ebb9e-5329-47a1-8284-9c5f8cfe9308@app.fastmail.com>
Date: Sat, 1 Nov 2025 21:41:02 +0200
Message-ID: <CAMW7n8AvCKYFUJhKCR=n0Rmm1BnF4Fzgq8fLa5nZW3=9zmVXLg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

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 nam=
e.

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 arbitrari=
ly.
And for Fibers to switch arbitrarily, backward compatibility must be broken=
.

What could be reused? The context-switching code and the observer
component handlers =E2=80=94 these were reused.
The issue isn=E2=80=99t that Fiber behavior can=E2=80=99t be changed, but t=
hat 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** =E2=80=94 thoughtfully and
consistently.
You can=E2=80=99t 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