Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128894
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 08:38:28 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8AFaUByiJ=2frgkAFWNPWHS2wYyHiKfwf8dzT7AYnLjWg@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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=58c6cb86f1e34bc6940021e472bf38e1
From: rob@bottled.codes ("Rob Landers")

--58c6cb86f1e34bc6940021e472bf38e1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2025, at 06:32, Edmond Dantes wrote:
> Hi
>=20
> > I don=E2=80=99t think it=E2=80=99s a =E2=80=9Crule=E2=80=9D per se a=
nd why I suggested breaking it up into two different kinds of Awaitables.
> > Invariants make code easier to reason about and work with. The more =
invariants you have, the easier it is to form, maintain, and refactor.
>=20
> So that is the rule: **invariants make code easier to understand**.
> A more general principle is stated as follows: reducing complexity.
>=20
> I think this point needs some thought.
> If the await operation is allowed only for Future, it will make the
> code more consistent which is a good thing.
>=20
> Then it will be necessary to add a FutureInterface, and Awaitable
> should be hidden from the UserLand namespace.

A simpler solution might be to keep things as they are, but have the non=
-idempotent constructs be generators of Awaitable instead of non-idempot=
ent Awaitables. This would basically mean just changing some text in the=
 RFC and some implementations that aren't documented in the RFC (as far =
as I can tell).

=E2=80=94 Rob
--58c6cb86f1e34bc6940021e472bf38e1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Oct =
22, 2025, at 06:32, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Hi</div><div><br></div><div>&gt; I don=E2=80=99=
t think it=E2=80=99s a =E2=80=9Crule=E2=80=9D per se and why I suggested=
 breaking it up into two different kinds of Awaitables.</div><div>&gt; I=
nvariants make code easier to reason about and work with. The more invar=
iants you have, the easier it is to form, maintain, and refactor.</div><=
div><br></div><div>So that is the rule: **invariants make code easier to=
 understand**.</div><div>A more general principle is stated as follows: =
reducing complexity.</div><div><br></div><div>I think this point needs s=
ome thought.</div><div>If the await operation is allowed only for Future=
, it will make the</div><div>code more consistent which is a good thing.=
</div><div><br></div><div>Then it will be necessary to add a FutureInter=
face, and Awaitable</div><div>should be hidden from the UserLand namespa=
ce.<br></div></blockquote><div><br></div><div>A simpler solution might b=
e to keep things as they are, but have the non-idempotent constructs be =
generators of Awaitable instead of non-idempotent Awaitables. This would=
 basically mean just changing some text in the RFC and some implementati=
ons that aren't documented in the RFC (as far as I can tell).</div><div>=
<br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--58c6cb86f1e34bc6940021e472bf38e1--