Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128930
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 23 Oct 2025 15:59:39 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <16c8de59-3890-469c-b9f5-c43f94dc7a33@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8AmU68iigDPsX+hcGhwXGjianddHAKkWdcrP0h5N_-8_g@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
 <CAMW7n8AgHnO0rBjqBkHNhfvV5PBNxwgHBJ762N3FtVxoh5WnOQ@mail.gmail.com>
 <E8D4A549-79EA-48E9-9D20-3608F357F227@trowski.com>
 <CAMW7n8D0wMNQE0zuMhbHstyZsDw=e7ryPPZERn11UFV7knmR-g@mail.gmail.com>
 <37180d8d-85b4-49a3-a672-334bf4329470@app.fastmail.com>
 <CAMW7n8AFaUByiJ=2frgkAFWNPWHS2wYyHiKfwf8dzT7AYnLjWg@mail.gmail.com>
 <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com>
 <CAMW7n8DKB+AWp2sWPi_w8ZgLQ_zS2MPNgP6n1G5127Nkk7EgOA@mail.gmail.com>
 <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
 <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
 <CAMW7n8C5KvtCZnEgh=hx_eGeBv32Gh5ngNa+Ug7dr4TYKRGa_w@mail.gmail.com>
 <CAMW7n8AmU68iigDPsX+hcGhwXGjianddHAKkWdcrP0h5N_-8_g@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=1efb19d09ed74f88b7cdc8b586f80d68
From: rob@bottled.codes ("Rob Landers")

--1efb19d09ed74f88b7cdc8b586f80d68
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Oct 23, 2025, at 13:08, Edmond Dantes wrote:
> Hello.
>=20
> It seems to me that the following solution balances the different
> viewpoints better:
>=20
> 1. Keep the base `Awaitable` interface, which defines an object that
> can be awaited.
> 2. Introduce a `FutureLike` interface that extends `Awaitable`.
> 3. Modify the `await()` function so that it only accepts `FutureLike` =
objects.
> 4. Functions such as `awaitAll` or `awaitAny` may need to be renamed,
> but that=E2=80=99s outside the scope of this RFC.
> 5. There will be no need to create a `Future` for functions designed
> to work with an `Awaitable` object =E2=80=94 this keeps the `select ca=
se`
> syntax clean.
>=20
> **Naming issue**
>=20
> I see a certain inconsistency between `await` and `Awaitable`.
> It might be worth coming up with a better name for `Awaitable`.
> I remember that =E2=80=9CObservable=E2=80=9D was once suggested.
>=20

Why not keep the name Awaitable instead of creating a FutureLike, but ju=
st harden the interface? We can always loosen the interface in the futur=
e, or create a new interface for "streaming" awaitables (aka, multi-shot=
 Awaitable). Then await() could change its signature from Async\await(Aw=
aitable $awaitable): mixed to Async\await(Awaitable|StreamingAwaitable $=
awaitable) at some point in the future -- and it would be BC.

=E2=80=94 Rob
--1efb19d09ed74f88b7cdc8b586f80d68
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Thu, Oct 23, 2025, at 13:08, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hello.</div><div=
><br></div><div>It seems to me that the following solution balances the =
different</div><div>viewpoints better:</div><div><br></div><div>1. Keep =
the base `Awaitable` interface, which defines an object that</div><div>c=
an be awaited.</div><div>2. Introduce a `FutureLike` interface that exte=
nds `Awaitable`.</div><div>3. Modify the `await()` function so that it o=
nly accepts `FutureLike` objects.</div><div>4. Functions such as `awaitA=
ll` or `awaitAny` may need to be renamed,</div><div>but that=E2=80=99s o=
utside the scope of this RFC.</div><div>5. There will be no need to crea=
te a `Future` for functions designed</div><div>to work with an `Awaitabl=
e` object =E2=80=94 this keeps the `select case`</div><div>syntax clean.=
</div><div><br></div><div>**Naming issue**</div><div><br></div><div>I se=
e a certain inconsistency between `await` and `Awaitable`.</div><div>It =
might be worth coming up with a better name for `Awaitable`.</div><div>I=
 remember that =E2=80=9CObservable=E2=80=9D was once suggested.</div><di=
v><br></div></blockquote><div><br></div><div>Why not keep the name Await=
able instead of creating a FutureLike, but just harden the interface? We=
 can always loosen the interface in the future, or create a new interfac=
e for "streaming" awaitables (aka, multi-shot Awaitable). Then await() c=
ould change its signature from Async\await(Awaitable $awaitable): mixed =
to Async\await(Awaitable|StreamingAwaitable $awaitable) at some point in=
 the future -- and it would be BC.</div><div><br></div><div id=3D"sig121=
229152">=E2=80=94 Rob</div></body></html>
--1efb19d09ed74f88b7cdc8b586f80d68--