Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130801
Feedback-ID: id5114917:Fastmail
Message-ID: <a11436e6-fafa-4150-9e18-abfc32c7f51e@rwec.co.uk>
Date: Thu, 7 May 2026 23:00:51 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Scope functions
To: internals@lists.php.net
References: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
 <6B83B07A-0344-4149-BFE9-7F3DD21BBA39@rwec.co.uk>
 <82D0F837-81DA-48D5-B467-35A8CCF52F9B@hotmail.com>
Content-Language: en-GB
In-Reply-To: <82D0F837-81DA-48D5-B467-35A8CCF52F9B@hotmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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 = bcadd($count, '1');
     $sum = bcadd($sum, $number);
});

foreach($numbers as $number) {
     $count = bcadd($count, '1');
     $sum = 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 = 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() === DBConnection::TRANSACTION_ABORT) {
       $conn->rollbackTran();
       return;
     }
   } catch (\Throwable $e) {
     $conn->rollback();
     throw $e;
   }
   $conn->commitTran();
}

transaction($connection) {
     $affectedRows = $connection->query("UPDATE ...");
     if ($affectedRows === 0) {
         break with DBConnection::TRANSACTION_ABORT;
     }
     // ...
}


I'm sure there are details here that wouldn't quite work as expressed, 
but hopefully it explains what I meant by wanting something closer to 
macros than closures.


Regards,

-- 
Rowan Tommins
[IMSoP]