Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129577
Feedback-ID: id5114917:Fastmail
Message-ID: <d5d0516c-61c6-4a8e-b755-0664fd6eabd7@rwec.co.uk>
Date: Tue, 9 Dec 2025 23:19:12 +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>
 <78bfa50ad7c5111a1c6caaff3a525255@bastelstu.be>
Content-Language: en-GB
In-Reply-To: <78bfa50ad7c5111a1c6caaff3a525255@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 27/11/2025 08:34, Tim Düsterhus wrote:

Hi Tim,

As promised, I eventually got back to this e-mail properly, and have 
updated the examples in response.

For convenience, here's the link again: https://gitlab.com/imsop/raii-vs-cm



>
> The block scoping RFC has been updated to `let()`.


Updated.


> 1.
>
> For db-transaction/implementation/1-raii-object.php I'd like to note 
> that it is not necessary to proxy execute() through the transaction 
> object. It could also be used as a simple guard object which only 
> purpose is to be constructed and destructed.


That's true. The "wikimedia-at-ease" example illustrates that style, 
because there aren't any methods we'd want there at all.

The drawback I see is that on a longer block, you have to come up with a 
name for that unused variable, and make sure you don't accidentally 
unset or overwrite it.


Apparently Java's workaround for that is to allow "unnamed variables", 
which have the expected lifetime, but can't be accessed: 
https://openjdk.org/jeps/456

try-with-resources is given as one of the example use cases ("var" 
infers the type; "_" in place of the name makes it an "unnamed variable"):

try (var _ = ScopedContext.acquire()) {
     ... no use of acquired resource ...
}

Notably, this is *not* the same meaning for "_" as, say, C#, where "_ = 
foo()" tells the compiler to discard the return value of foo(): 
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/discards


In the case of a transaction, it feels logical for at least the commit() 
and rollback() methods to be on the Transaction class, but other methods 
would be a matter of style. I've removed execute() to take the simplest 
route.


>
> 2.
>
> The RAII object in 'file-handle' serves no purpose. PHP will already 
> call `fclose()` when the resource itself goes out of scope, so this is 
> existing behavior with extra steps. The same is true for the 
> 0-linear-code example in file-object. You don't need the `fclose()` 
> there.


This is true as long as nothing stores an additional reference to the 
file handle. Having a separate "guard object" doesn't fully prevent this 
- a reference to the guard object itself could leak - but does make it 
less likely.

It also gives somewhere to customise the open and close behaviour, such 
as adding locking, or converting false-on-error to an exception (more on 
that below).


To see what it looks like, I've added a "file-handle-unguarded" 
scenario, which exposes the handle much more directly: it doesn't force 
fclose(), and leaves the application to handle the failure of fopen()

The CM example benefits from being able to "break" out of the using{} 
block; as far as I can see, the current RFC doesn't allow that from a 
let{} block, is that correct?



>
> 3.
>
> The docblock in locked-pdf/application/2-context-manager.php is 
> incorrectly copy and pasted.


Well spotted. Fixed.


> I was about to comment that the 'file' examples were not equivalent, 
> because the context manager and IOC ones didn't include the error 
> logging, until I noticed it was hidden away in the implementation. 
> This probably suggests that I implicitly expected to see all relevant 
> control flow. Exception handling and logging in particular probably 
> greatly depend on the surrounding context to be useful (e.g. to adapt 
> the log message or to enhance it with additional context data). So 
> while it might superficially look cleaner / simpler, I feel that this 
> kind of generic handling will bite you sooner or later. So with the 
> context manager example, I would expect the “exception introspection” 
> capability to be used to properly tear down the context, but not for 
> cross-cutting concerns such as logging.


That's a reasonable comment. Looking at those examples more closely, I 
realise I actually messed up the error handling in most of them - they 
never check for the false returned by fopen()

I've moved the logging out into the "application", but updated all the 
"implementations" to throw a "FileOpeningException" if fopen() returns 
false.

This really demonstrates the value of the "try using() { ... }" 
short-hand Larry & Arnaud have added to the CM RFC - we need the try to 
be on the *outside* of the block to catch the new exception. I presume a 
similar "try let() { ... }" could be added to yours?


It's interesting how similar the example end up for simple scenarios, 
but I think if we had block-scoped variables, I'd still like Context 
Managers for some of the more complex cases.


-- 
Rowan Tommins
[IMSoP]