Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128925
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 23 Oct 2025 10:18:23 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <51a4f8e0-2dbe-444c-aeda-162020c022c5@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8C5KvtCZnEgh=hx_eGeBv32Gh5ngNa+Ug7dr4TYKRGa_w@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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=57ef65230f18472ea97d4012c2ba1960
From: rob@bottled.codes ("Rob Landers")

--57ef65230f18472ea97d4012c2ba1960
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Oct 23, 2025, at 09:59, Edmond Dantes wrote:
> I=E2=80=99d like you to have the full information necessary to make an
> informed decision.
>=20
> There are two or more channel objects that need to be awaited. How
> should this be implemented?
>=20
> Currently
> ```php
> [$result1, $result2] =3D awaitAny($channel1, $channel2);
> ```
>=20
> With Futures:
> ```php
> // Like Rust
> [$result1, $result2] =3D awaitAny($channel1->recv(), $channel2->recv()=
);
> ```
>=20
> What I dislike about the Future example is that it creates an object
> that isn=E2=80=99t actually needed.
> What I like about it is that it clearly shows what action is being awa=
ited.

Specifically:

> What I dislike about the Future example is that it creates an object
> that isn=E2=80=99t actually needed.

Why does it need to 'create' an object? Flyweights are a well known patt=
ern and PHP knows the number of references to any specific object. Preve=
nt them from being GC'd and have a pool of them for reuse. You don't nee=
d to actually create anything. That being said, that's an optimization f=
or later.

As for which one I'd rather have, I'd rather have the one where my examp=
les hold true:

assert(awaitAll($a, $b, $c) =3D=3D=3D [await($a), await($b), await($c)]);

It's clear what it does and that it is just a shorthand. When that fails=
, we have issues.

=E2=80=94 Rob
--57ef65230f18472ea97d4012c2ba1960
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 09:59, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>I=E2=80=99d like=
 you to have the full information necessary to make an</div><div>informe=
d decision.</div><div><br></div><div>There are two or more channel objec=
ts that need to be awaited. How</div><div>should this be implemented?</d=
iv><div><br></div><div>Currently</div><div>```php</div><div>[$result1, $=
result2] =3D awaitAny($channel1, $channel2);</div><div>```</div><div><br=
></div><div>With Futures:</div><div>```php</div><div>// Like Rust</div><=
div>[$result1, $result2] =3D awaitAny($channel1-&gt;recv(), $channel2-&g=
t;recv());</div><div>```<br></div><div><br></div><div>What I dislike abo=
ut the Future example is that it creates an object</div><div>that isn=E2=
=80=99t actually needed.</div><div>What I like about it is that it clear=
ly shows what action is being awaited.</div></blockquote><div><br></div>=
<div>Specifically:</div><div><br></div><blockquote type=3D"cite" id=3D"q=
t" style=3D""><div>What I dislike about the Future example is that it cr=
eates an object</div><div>that isn=E2=80=99t actually needed.</div></blo=
ckquote><div><br></div><div>Why does it need to 'create' an object? Flyw=
eights are a well known pattern and PHP knows the number of references t=
o any specific object. Prevent them from being GC'd and have a pool of t=
hem for reuse. You don't need to actually create anything. That being sa=
id, that's an optimization for later.</div><div><br></div><div>As for wh=
ich one I'd rather have, I'd rather have the one where my examples hold =
true:</div><div><br></div><div>assert(awaitAll($a, $b, $c) =3D=3D=3D [aw=
ait($a), await($b), await($c)]);</div><div><br></div><div>It's clear wha=
t it does and that it is just a shorthand. When that fails, we have issu=
es.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></bo=
dy></html>
--57ef65230f18472ea97d4012c2ba1960--