Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126642
Date: Sat, 8 Mar 2025 11:58:01 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <db71834a-9ba7-47d3-8d06-0531eee9f0a0@gmail.com>
In-Reply-To: <05c426b4-4cea-46c3-9013-aa6cfb8b18b4@app.fastmail.com>
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> <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com> <05c426b4-4cea-46c3-9013-aa6cfb8b18b4@app.fastmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_18_258601567.1741431481612"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_18_258601567.1741431481612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> you=C2=A0//never// get to decide unless you wrap it in a specific form (a=
sync\run or async\async, in this RFC), which ironically colors the function=
.

You're wrong, it does *not* color the function: spawning a new fiber does n=
ot make the code running it async: it is always async, regardless of whethe=
r you use async() or not, but when not using async(), it's simply the only =
async execution flow running.

> can't think of any way around it. My biggest issue with this RFC is that =
it results in=C2=A0**multiple** colors: FiberHandle, Future, and Resume.=C2=
=A0


You misunderstand again, colors are not objects or classes, colors are spec=
ial and annoying keywords (red, blue, await) that must always be added to c=
all functions of the same color (red, blue, await).

The FiberHandle is literally just a handle associated with the execution fl=
ow spawned with async(), it is not in any way associated with the spawned f=
unction, nor it is required in any way to invoke the spawned function.

Adding colors to functions makes async unnecessarily complex to use, for no=
 good reason at all (no, forcing developers to explicitly know if a functio=
n is async or not is not a good enough reason, when I write code I want to =
get things done, when I want to parallelize execution of something I use go=
/async(), when I don't, I couldn't care less about what the function does i=
nside, and I especially do not want to do a lot of hoop jumping to use it o=
r use other common patterns like functional composition).

Again, take a look at how nicely golang handles concurrency with colorless =
functions: php fibers weren't the first to do it.

Regards,
Daniil Gentili.

------=_Part_18_258601567.1741431481612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
 <head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
 </head>
 <body>
  <span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; you&nbsp;//never// get to decide unless you wrap it in a specific form (async\run or async\async, in this RFC), which ironically colors the function. </span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">You're wrong, it does *not* color the function: spawning a new fiber does not make the code running it async: it is always async, regardless of whether you use async() or not, but when not using async(), it's simply the only async execution flow running.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; can't think of any way around it. My biggest issue with this RFC is that it results in&nbsp;**multiple** colors: FiberHandle, Future, and Resume.&nbsp;</span>
  <br>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">You misunderstand again, colors are not objects or classes, colors are special and annoying keywords (red, blue, await) that must always be added to call functions of the same color (red, blue, await).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">The FiberHandle is literally just a handle associated with the execution flow spawned with async(), it is not in any way associated with the spawned function, nor it is required in any way to invoke the spawned function.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Adding colors to functions makes async unnecessarily complex to use, for no good reason at all (no, forcing developers to explicitly know if a function is async or not is not a good enough reason, when I write code I want to get things done, when I want to parallelize execution of something I use go/async(), when I don't, I couldn't care less about what the function does inside, and I especially do not want to do a lot of hoop jumping to use it or use other common patterns like functional composition).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Again, take a look at how nicely golang handles concurrency with colorless functions: php fibers weren't the first to do it.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Regards,</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Daniil Gentili.</span>
  <br>
 </body>
</html>
------=_Part_18_258601567.1741431481612--