Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129315
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------PpqcY7v5LK0WbzOA8P4HWra3"
Message-ID: <fb2d1f83-142b-4bf8-a28d-e769ff2d48c4@rwec.co.uk>
Date: Wed, 19 Nov 2025 22:19:23 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Examples comparing Block Scoped RAII and Context
 Managers
To: internals@lists.php.net
References: <26a2f13c-f318-4d6c-9595-bfaaebcbabcb@rwec.co.uk>
 <432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------PpqcY7v5LK0WbzOA8P4HWra3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18/11/2025 17:23, Larry Garfield wrote:
> One thing I definitely do not like is the need for a `FileWrapper` class in the RAII file-handle example.  That seems like an unnecessary level of abstraction just to squeeze the `fclose()` value onto the file handle.  The fully-separated Context Manager seems a more flexible approach.


Yes, exploring how exactly that flexibility could be used was part of my 
motivation for the examples I picked.

The downside is that it is slightly harder to understand at first 
glance: someone reading "using (file_for_write('file.txt') as $fh)" 
might well assume that $fh is the value returned from 
"file_for_write('file.txt')", rather than the value returned from 
"file_for_write('file.txt')->enterContext()".

What made sense to me was comparing to an Iterator that only goes around 
once - in "foreach (files_to_write_to() as $fh)", the 
"files_to_write_to()" call doesn't return $fh either, 
"files_to_write_to()->current()" does.


> I also noted that all of the examples wrap the context block (of whichever syntax) in a try-catch of its own.  I don't know if that's going to be a common pattern or not.  If so, might it suggest that the `using` block have its own built-in optional `catch` and `finally` for one-off additional handling?  That could point toward the Java approach of merging this functionality into `try`, but I am concerned about the implications of making both `catch` and `finally` effectively optional on `try` blocks.  I am open to discussion on this front.  (Anyone know what the typical use cases are in Python?)


Looking at the parser, I realised that a "try" block with neither 
"catch" nor "finally" actually matches the grammar; it is only rejected 
by a specific check when compiling the AST to opcodes. Without that 
check, it would just compile to some unnecessary jump table entries.


I guess an alternative would be allowing any statement after the using() 
rather than always a block, as in Seifeddine and Tim's proposal, which 
allows you to stack like this:

using ($db->transactionScope()) try {
     // ...
}
catch ( SomeSpecificException $e ) {
     // ...
}

Or, the specific combination "try using( ... )" could be added to the 
parser. (At the moment, "try" must always be followed by "{".)


As I noted in one of the examples 
(file-handle/application/1b-raii-with-scope-block.php), there is a 
subtle difference in semantics between different nesting orders - with 
"try using()", you can catch exceptions thrown by enterContext() and 
exitContext(); with "using() try", you can catch exceptions before 
exitContext() sees them and cleans up.

It seems Java's try-with-resources is equivalent to "try using()":

 >  In a try-with-resources statement, any catch or finally block is run 
after the resources declared have been closed.


> Regarding `let`, I think there's promise in such a keyword to opt-in to "unset this at the end of this lexical block."  However, it's also off topic from everything else here, as I think it's very obvious now that the need to do more than just `unset()` is common.  Sneaking hidden "but if it also implements this magic interface then it gets a bonus almost-destructor" into it is non-obvious magic that I'd oppose.  I'd be open to a `let` RFC on its own later (which would likely also make sense in `foreach` and various other places), but it's not a solution to the "packaged setup/teardown" problem.


I completely agree. I think an opt-in for block scope would be useful in 
a number of places, and resource management is probably the wrong focus 
for designing it. For instance, it would give a clear opt-out 
for capture-by-default closures:

function foo() {
    // ... code setting lots of variables ...
    $callback = function() use (*) {
         let $definitelyNotCaptured=null;
         // ... code mixing captured and local variables ...
     }
}


> Which is exactly the benefit of the separation of the Context Manager from the Context Variable.  The CM can be written to rely on `unset()` closing the object (risk 2), or to handle closing it itself (risk 1), as the developer determines.


Something the examples I picked don't really showcase is that a Context 
Manager doesn't need to be specialised to a particular task at all, it 
can generically implement one of these strategies.

The general pattern is this:

class GeneralPurposeCM implements ContextManager {
     public function __construct(private object $contextVar) {}
     public function enterContext(): object { return $this->contextVar; }
     public functoin exitContext(): void {}
}

- On its own, that makes "using(new GeneralPurposeCM(new Something) as 
$foo) { ... }" a very over-engineered version of "{ let $foo = new 
Something; ... }"

- To emulate C#, constrain to "IDisposable $contextVar", and call 
"$this->contextVar->Dispose()" in exitContext()

- To emulate Java, constrain to "AutoCloseable $contextVar" and call 
"$this->contextVar->close()" in exitContext()

- To throw a runtime error if the context variable still has references 
after the block, swap "$this->contextVar" for a WeakReference in 
beginContext(); then check for "$this->contextVarWeakRef->get() !== 
null" in exitContext()

- To have objects that "lock and unlock themselves", constrain to 
"Lockable $contextVar", then call "$this->contextVar->lock()" in 
beginContext() and "$this->contextVar->unlock()" in exitContext()


The only things you can't emulate are:

1) The extra syntax options provided by other languages, like C#'s 
"using Something foo = whatever();" or Go's "defer 
some_function(something);"

2) Compile-time guarantees that the Context Variable will not still have 
references after the block, like in Hack. I don't think that's a 
realistic goal for PHP.


Incidentally, while checking I had the right method name in the above, I 
noticed the Context Manager RFC has an example using "leaveContext" 
instead, presumably an editing error. :)


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------PpqcY7v5LK0WbzOA8P4HWra3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 18/11/2025 17:23, Larry Garfield
      wrote:<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">One thing I definitely do not like is the need for a `FileWrapper` class in the RAII file-handle example.  That seems like an unnecessary level of abstraction just to squeeze the `fclose()` value onto the file handle.  The fully-separated Context Manager seems a more flexible approach.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, exploring how exactly that flexibility could be used was
      part of my motivation for the examples I picked. </p>
    <p>The downside is that it is slightly harder to understand at first
      glance: someone reading "using (file_for_write('file.txt') as
      $fh)" might well assume that $fh is the value returned from
      "file_for_write('file.txt')", rather than the value returned from
      "file_for_write('file.txt')-&gt;enterContext()".</p>
    <p>What made sense to me was comparing to an Iterator that only goes
      around once - in "foreach (files_to_write_to() as $fh)", the "files_to_write_to()"
      call doesn't return $fh either, "files_to_write_to()-&gt;current()"
      does.</p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
      cite="mid:432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">I also noted that all of the examples wrap the context block (of whichever syntax) in a try-catch of its own.  I don't know if that's going to be a common pattern or not.  If so, might it suggest that the `using` block have its own built-in optional `catch` and `finally` for one-off additional handling?  That could point toward the Java approach of merging this functionality into `try`, but I am concerned about the implications of making both `catch` and `finally` effectively optional on `try` blocks.  I am open to discussion on this front.  (Anyone know what the typical use cases are in Python?)</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Looking at the parser, I realised that a "try" block with neither
      "catch" nor "finally" actually matches the grammar; it is only
      rejected by a specific check when compiling the AST to opcodes.
      Without that check, it would just compile to some unnecessary jump
      table entries.</p>
    <p><br>
    </p>
    <p>I guess an alternative would be allowing any statement after the
      using() rather than always a block, as in Seifeddine and Tim's
      proposal, which allows you to stack like this:</p>
    <p>using ($db-&gt;transactionScope()) try {<br>
          // ...<br>
      }<br>
      catch ( SomeSpecificException $e ) {<br>
          // ...<br>
      }</p>
    <p>Or, the specific combination "try using( ... )" could be added to
      the parser. (At the moment, "try" must always be followed by "{".)</p>
    <p><br>
    </p>
    <p>As I noted in one of the examples
      (file-handle/application/1b-raii-with-scope-block.php), there is a
      subtle difference in semantics between different nesting orders -
      with "try using()", you can catch exceptions thrown by
      enterContext() and exitContext(); with "using() try", you can
      catch exceptions before exitContext() sees them and cleans up.</p>
    <p>It seems Java's try-with-resources is equivalent to "try
      using()":</p>
    <p>&gt;  In a try-with-resources statement, any catch or finally
      block is run after the resources declared have been closed.<br>
      <br>
    </p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Regarding `let`, I think there's promise in such a keyword to opt-in to "unset this at the end of this lexical block."  However, it's also off topic from everything else here, as I think it's very obvious now that the need to do more than just `unset()` is common.  Sneaking hidden "but if it also implements this magic interface then it gets a bonus almost-destructor" into it is non-obvious magic that I'd oppose.  I'd be open to a `let` RFC on its own later (which would likely also make sense in `foreach` and various other places), but it's not a solution to the "packaged setup/teardown" problem.</pre>
      </blockquote>
      <br>
    </p>
    <p><br>
    </p>
    <p>I completely agree. I think an opt-in for block scope would be
      useful in a number of places, and resource management is probably
      the wrong focus for designing it. For instance, it would give a
      clear opt-out for capture-by-default closures:</p>
    <p>function foo() {<br>
         // ... code setting lots of variables ...<br>
         $callback = function() use (*) {<br>
              let $definitelyNotCaptured=null;<br>
              // ... code mixing captured and local variables ...<br>
          }<br>
      }</p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
      cite="mid:432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">Which is exactly the benefit of the separation of the Context Manager from the Context Variable.  The CM can be written to rely on `unset()` closing the object (risk 2), or to handle closing it itself (risk 1), as the developer determines.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Something the examples I picked don't really showcase is that a
      Context Manager doesn't need to be specialised to a particular
      task at all, it can generically implement one of these strategies.</p>
    <p>The general pattern is this:</p>
    <p>class GeneralPurposeCM implements ContextManager {<br>
          public function __construct(private object $contextVar) {}<br>
          public function enterContext(): object { return
      $this-&gt;contextVar; }<br>
          public functoin exitContext(): void {}<br>
      }</p>
    <p>- On its own, that makes "using(new GeneralPurposeCM(new
      Something) as $foo) { ... }" a very over-engineered version of "{
      let $foo = new Something; ... }"</p>
    <p>- To emulate C#, constrain to "IDisposable $contextVar", and call
      "$this-&gt;contextVar-&gt;Dispose()" in exitContext()</p>
    <p>- To emulate Java, constrain to "AutoCloseable $contextVar" and
      call "$this-&gt;contextVar-&gt;close()" in exitContext()</p>
    <p>- To throw a runtime error if the context variable still has
      references after the block, swap "$this-&gt;contextVar" for a
      WeakReference in beginContext(); then check for
      "$this-&gt;contextVarWeakRef-&gt;get() !== null" in exitContext()</p>
    <p>- To have objects that "lock and unlock themselves", constrain to
      "Lockable $contextVar", then call
      "$this-&gt;contextVar-&gt;lock()" in beginContext() and
      "$this-&gt;contextVar-&gt;unlock()" in exitContext()</p>
    <p><br>
    </p>
    <p>The only things you can't emulate are:</p>
    <p>1) The extra syntax options provided by other languages, like
      C#'s "using Something foo = whatever();" or Go's "defer
      some_function(something);"</p>
    <p>2) Compile-time guarantees that the Context Variable will not
      still have references after the block, like in Hack. I don't think
      that's a realistic goal for PHP.</p>
    <p><br>
    </p>
    <p>Incidentally, while checking I had the right method name in the
      above, I noticed the Context Manager RFC has an example using
      "leaveContext" instead, presumably an editing error. :)</p>
    <p><br>
    </p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------PpqcY7v5LK0WbzOA8P4HWra3--