Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130802
Precedence: list
MIME-Version: 1.0
References: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
 <6B83B07A-0344-4149-BFE9-7F3DD21BBA39@rwec.co.uk> <82D0F837-81DA-48D5-B467-35A8CCF52F9B@hotmail.com>
 <a11436e6-fafa-4150-9e18-abfc32c7f51e@rwec.co.uk>
In-Reply-To: <a11436e6-fafa-4150-9e18-abfc32c7f51e@rwec.co.uk>
Date: Thu, 7 May 2026 21:56:15 -0300
Message-ID: <CADK1yX+K+2mOLQr9muL1m0rgviqkDRw-goTrddLDzjYbSBc9uw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scope functions
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000ce11b4065143dd46"
From: deleugyn@gmail.com (Deleu)

--000000000000ce11b4065143dd46
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 7 May 2026 at 19:03 Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>
wrote:

> On 07/05/2026 13:16, Bob Weinand wrote:
> > I am not opposed at all to such a consistent macro system though.
> > ... but I would not make a transaction like that a macro. For inlining
> variables in a html or sql snippet with proper escaping, definitely great=
.
> > To me, macros should meaningfully transform their contained code rather
> than wrapping a bit of logic around, which would be covered by this RFC.
> > It's complimentary, not a replacement.
>
>
> Thinking about this further, I agree that full-blooded macros would be
> overkill for this case, but my starting point was that closures don't
> feel like the right solution either - they're a different feature being
> bent into shape.
>
> So rather than starting with a Closure, and taking things away, I was
> trying to think of ways to start with a simple block of code, and build
> it up.
>
>
> For instance, the array_walk example in the RFC is just an ugly (and
> probably inefficient) way of writing a foreach loop:
>
> array_walk($numbers, fn($number) {
>      $count =3D bcadd($count, '1');
>      $sum =3D bcadd($sum, $number);
> });
>
> foreach($numbers as $number) {
>      $count =3D bcadd($count, '1');
>      $sum =3D bcadd($sum, $number);
> }
>
> So, what would it look like to generalise that, so we could do the same
> for other scenarios, like async() and transaction()?
>
>
> A simple first step would be something that could take a block of code,
> and say when to execute it:
>
> custom_block transaction($dbConnection) {
>      try {
>          $dbConnection->beginTransaction();
>          __execute_block_body();
>      }
>      catch (\Throwable $e) {
>          $dbConnection->rollbackTransaction();
>          throw $e;
>       }
>       $dbConnection->commitTransaction();
> }
>
> transaction($myDb) {
>      $myDb->query('UPDATE ...');
> }
>
> If the block body is never represented as a variable, there's no need to
> define what happens when it outlives scope, or the user tries to clone
> it, rebind it, etc.
>
> And if the calling code doesn't look like it's creating a Closure, users
> won't have any wrong expectations about variable scopes or lifetimes.
>
>
> Onto that, we can add syntax to push values into the block, e.g. using
> the "as" keyword like in "foreach" (example based on the "Generator
> decorator managers" section at the end of the Context Managers RFC):
>
> custom_block opening($filename) {
>      $f =3D fopen($filename, "r");
>      if (!$f) {
>          throw new Exception("fopen($filename) failed");
>      }
>      try {
>          __execute_block_body($f);
>      } finally {
>          fclose($f);
>      }
> }
>
> opening(__FILE__ as $f) {
>      var_dump($f);
> }
>
>
> And some way to pull values out, e.g. a "break with" keyword:
>
> custom_block transaction(DBConnection $conn) {
>    $conn->beginTran();
>    try {
>      if (__execute_block_body() =3D=3D=3D DBConnection::TRANSACTION_ABORT=
) {
>        $conn->rollbackTran();
>        return;
>      }
>    } catch (\Throwable $e) {
>      $conn->rollback();
>      throw $e;
>    }
>    $conn->commitTran();
> }
>
> transaction($connection) {
>      $affectedRows =3D $connection->query("UPDATE ...");
>      if ($affectedRows =3D=3D=3D 0) {
>          break with DBConnection::TRANSACTION_ABORT;
>      }
>      // ...
> }



That looks like a function (aka closure) with a lot of weird extra steps.
It=E2=80=99s been years, several proposals and multiple demonstrations on h=
ow arrow
function syntax can be expanded to be useful with multi-statements. So much
gymnastics goes on to deny such a simple and elegant syntax.

>

--000000000000ce11b4065143dd46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">On Thu, 7 May 2026 at 19:03 Rowan Tommins [IMSoP] &lt;<a =
href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br=
></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex" dir=3D"auto">On 07/05/2026=
 13:16, Bob Weinand wrote:<br>
&gt; I am not opposed at all to such a consistent macro system though.<br>
&gt; ... but I would not make a transaction like that a macro. For inlining=
 variables in a html or sql snippet with proper escaping, definitely great.=
<br>
&gt; To me, macros should meaningfully transform their contained code rathe=
r than wrapping a bit of logic around, which would be covered by this RFC.<=
br>
&gt; It&#39;s complimentary, not a replacement.<br>
<br>
<br>
Thinking about this further, I agree that full-blooded macros would be <br>
overkill for this case, but my starting point was that closures don&#39;t <=
br>
feel like the right solution either - they&#39;re a different feature being=
 <br>
bent into shape.<br>
<br>
So rather than starting with a Closure, and taking things away, I was <br>
trying to think of ways to start with a simple block of code, and build <br=
>
it up.<br>
<br>
<br>
For instance, the array_walk example in the RFC is just an ugly (and <br>
probably inefficient) way of writing a foreach loop:<br>
<br>
array_walk($numbers, fn($number) {<br>
=C2=A0=C2=A0 =C2=A0 $count =3D bcadd($count, &#39;1&#39;);<br>
=C2=A0=C2=A0 =C2=A0 $sum =3D bcadd($sum, $number);<br>
});<br>
<br>
foreach($numbers as $number) {<br>
=C2=A0=C2=A0 =C2=A0 $count =3D bcadd($count, &#39;1&#39;);<br>
=C2=A0=C2=A0 =C2=A0 $sum =3D bcadd($sum, $number);<br>
}<br>
<br>
So, what would it look like to generalise that, so we could do the same <br=
>
for other scenarios, like async() and transaction()?<br>
<br>
<br>
A simple first step would be something that could take a block of code, <br=
>
and say when to execute it:<br>
<br>
custom_block transaction($dbConnection) {<br>
=C2=A0=C2=A0 =C2=A0 try {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 $dbConnection-&gt;beginTransaction();<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0__execute_block_body();<br>
=C2=A0=C2=A0 =C2=A0 }<br>
=C2=A0=C2=A0 =C2=A0 catch (\Throwable $e) {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0$dbConnection-&gt;rollbackTransactio=
n();<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw $e;<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0$dbConnection-&gt;commitTransaction();<br>
}<br>
<br>
transaction($myDb) {<br>
=C2=A0=C2=A0 =C2=A0 $myDb-&gt;query(&#39;UPDATE ...&#39;);<br>
}<br>
<br>
If the block body is never represented as a variable, there&#39;s no need t=
o <br>
define what happens when it outlives scope, or the user tries to clone <br>
it, rebind it, etc.<br>
<br>
And if the calling code doesn&#39;t look like it&#39;s creating a Closure, =
users <br>
won&#39;t have any wrong expectations about variable scopes or lifetimes.<b=
r>
<br>
<br>
Onto that, we can add syntax to push values into the block, e.g. using <br>
the &quot;as&quot; keyword like in &quot;foreach&quot; (example based on th=
e &quot;Generator <br>
decorator managers&quot; section at the end of the Context Managers RFC):<b=
r>
<br>
custom_block opening($filename) {<br>
=C2=A0=C2=A0 =C2=A0 $f =3D fopen($filename, &quot;r&quot;);<br>
=C2=A0=C2=A0 =C2=A0 if (!$f) {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new Exception(&quot;fopen($filename=
) failed&quot;);<br>
=C2=A0=C2=A0 =C2=A0 }<br>
=C2=A0=C2=A0 =C2=A0 try {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0__execute_block_body($f);<br>
=C2=A0=C2=A0 =C2=A0 } finally {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 fclose($f);<br>
=C2=A0=C2=A0 =C2=A0 }<br>
}<br>
<br>
opening(__FILE__ as $f) {<br>
=C2=A0=C2=A0 =C2=A0 var_dump($f);<br>
}<br>
<br>
<br>
And some way to pull values out, e.g. a &quot;break with&quot; keyword:<br>
<br>
custom_block transaction(DBConnection $conn) {<br>
=C2=A0=C2=A0 $conn-&gt;beginTran();<br>
=C2=A0=C2=A0 try {<br>
=C2=A0=C2=A0 =C2=A0 if (__execute_block_body() =3D=3D=3D DBConnection::TRAN=
SACTION_ABORT) {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 $conn-&gt;rollbackTran();<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 return;<br>
=C2=A0=C2=A0 =C2=A0 }<br>
=C2=A0=C2=A0 } catch (\Throwable $e) {<br>
=C2=A0=C2=A0 =C2=A0 $conn-&gt;rollback();<br>
=C2=A0=C2=A0 =C2=A0 throw $e;<br>
=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0 $conn-&gt;commitTran();<br>
}<br>
<br>
transaction($connection) {<br>
=C2=A0=C2=A0 =C2=A0 $affectedRows =3D $connection-&gt;query(&quot;UPDATE ..=
.&quot;);<br>
=C2=A0=C2=A0 =C2=A0 if ($affectedRows =3D=3D=3D 0) {<br>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 break with DBConnection::TRANSACTION_ABOR=
T;<br>
=C2=A0=C2=A0 =C2=A0 }<br>
=C2=A0=C2=A0 =C2=A0 // ...<br>
}</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">That looks like a function (aka closure) with a lot of weird=
=C2=A0extra steps. It=E2=80=99s been years, several proposals and multiple =
demonstrations on how arrow function syntax can be expanded to be useful wi=
th multi-statements. So much gymnastics goes on to deny such a simple and e=
legant syntax.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" dir=
=3D"auto"></blockquote></div></div>

--000000000000ce11b4065143dd46--