Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126636
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com> <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
In-Reply-To: <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
Date: Sat, 8 Mar 2025 10:24:52 +0200
Message-ID: <CAMW7n8BN6kNny3CRxKEtCWari5eQ0uCj42g2xQLjFqXCkyF=Rw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c7dce6062fd07983"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000c7dce6062fd07983
Content-Type: text/plain; charset="UTF-8"

>
>for($i = 0; $i < 10; $i++) $results[] = async\async(fn($f) =>
file_get_contents($f),
> $file[$i]);
> // convert $results into futures somehow -- though actually doesn't look
like it is
> possible.
> $results = async\awaitAll($results);
>

Future can be obtained via getFuture(), according to the current RFC.
```php
async\async(fn($f) => file_get_contents($f), $file[$i])->getFuture();
```

And this semantics can be simplified to:
```async file_get_contents($file[$i]);```
or
```spawn file_get_contents($file[$i]);```

From this perspective, I like that any function can be called with
spawn/async without worrying about its internals or modifying its code. The
pros and cons of this approach are well known.

--000000000000c7dce6062fd07983
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<br>&gt;for($i =3D 0; $i &lt; 10; $i++) $results=
[] =3D async\async(fn($f) =3D&gt; file_get_contents($f),<br>&gt; $file[$i])=
;<br>&gt; // convert $results into futures somehow -- though actually doesn=
&#39;t look like it is<br>&gt; possible.<br>&gt; $results =3D async\awaitAl=
l($results);<br>&gt;<br><br><code>Future</code> can be obtained via <code>g=
etFuture()</code>, according to the current RFC.<div>```php</div><div>async=
\async(fn($f) =3D&gt; file_get_contents($f), $file[$i])-&gt;getFuture();<br=
>```=C2=A0=C2=A0<br><br></div><div>And this semantics can be simplified to:=
=C2=A0=C2=A0<br>```async file_get_contents($file[$i]);```<br>or<br>```spawn=
 file_get_contents($file[$i]);```</div><div><br></div><div>From this perspe=
ctive, I like that any function can be called with <code>spawn/async</code>=
 without worrying about its internals or modifying its code. The pros and c=
ons of this approach are well known.=C2=A0=C2=A0</div></div>

--000000000000c7dce6062fd07983--