Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129288
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 18 Nov 2025 11:23:35 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <432ca4ad-7bcc-43bd-8e05-3121839b4ff7@app.fastmail.com>
In-Reply-To: <26a2f13c-f318-4d6c-9595-bfaaebcbabcb@rwec.co.uk>
References: <26a2f13c-f318-4d6c-9595-bfaaebcbabcb@rwec.co.uk>
Subject: Re: [PHP-DEV] Examples comparing Block Scoped RAII and Context Managers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Nov 15, 2025, at 5:11 PM, Rowan Tommins [IMSoP] wrote:
> Hi all,
>
> The Block Scoping RFC=C2=A0and the Context Manager RFC cover a lot of =
similar=20
> use cases, and a lot of the discussion on both threads has been=20
> explicitly comparing them.
>
> To try to picture better how they compare, I have put together a set o=
f=20
> examples that implement the same code using both features, as well as=20
> some other variations, in this git repo: https://gitlab.com/imsop/raii=
-vs-cm
>
> A few notes:
>
> - The syntax for the two proposals is based on the current RFC text. I=
f=20
> they are updated, e.g. to use different keywords, I will update the=20
> examples.
>
> - I have included examples with=C2=A0closures which automatically capt=
ure by=20
> value, since a lot of the same use cases come up when discussing those.
>
> - There are many scenarios which could be included, and many ways each=20
> example could be written. I have chosen scenarios to=C2=A0illustrate c=
ertain=20
> strengths and weaknesses, but tried to fairly represent a "good" use o=
f=20
> each feature. However, I welcome feedback about unintentional bias in =
my=20
> choices.
>
> - Corrections and additional examples are welcome as Merge Requests to=20
> the repo, or replies here.
>
>
> With that out of the way, here are my own initial thoughts from workin=
g=20
> through the examples:
>
> - RAII + block scope is most convenient when protecting=C2=A0an existi=
ng=20
> object which can be edited or extended.
>
> - When protecting a final object, or a native resource, RAII is harder=20
> to implement. In these cases, the separation of Context Manager from=20
> managed value is powerful.
>
> - Context Managers are very concise for safely setting and resetting=20
> global state. RAII can achieve this, but feels less natural.
>
> - An=C2=A0"inversion of control" approach (passing in a callback with =
the=20
> body of the protected block) requires capturing all variables *not*=20
> scoped to the block. Even with automatic by-value capture, those neede=
d=20
> *after* the block would need to be listed for capture by reference.
>
> - Building a Context Manager from a Generator can lead to very readabl=
e=20
> code in some cases, and closely mimics an "inversion of control"=20
> approach without the same variable capture problems.
>
>
> I would be interested in other people's thoughts.
>
> Regards,
>
> --=20
> Rowan Tommins
> [IMSoP]

Thank you to Rowan for the in depth comparison!

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.

Suppose we were dealing with a considerably more involved object than a =
file handle, with a large interface.  You'd need to either

1. Extend the class, and we all know about extends...
2. Make a wrapper that passes through the calls (which could be very ver=
bose)
3. Do as is done here, with a simple dumb wrapper, which means in the bo=
dy of the context block you have to do `$var->val` all the time, which i=
s just clunky.

Fully separating the Context Manager from the Context Variable completel=
y avoids that issue.


I also noted that all of the examples wrap the context block (of whichev=
er syntax) in a try-catch of its own.  I don't know if that's going to b=
e a common pattern or not.  If so, might it suggest that the `using` blo=
ck have its own built-in optional `catch` and `finally` for one-off addi=
tional handling?  That could point toward the Java approach of merging t=
his functionality into `try`, but I am concerned about the implications =
of making both `catch` and `finally` effectively optional on `try` block=
s.  I am open to discussion on this front.  (Anyone know what the typica=
l use cases are in Python?)


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 t=
opic from everything else here, as I think it's very obvious now that th=
e need to do more than just `unset()` is common.  Sneaking hidden "but i=
f it also implements this magic interface then it gets a bonus almost-de=
structor" 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 `for=
each` and various other places), but it's not a solution to the "package=
d setup/teardown" problem.

---

Another thing that occurs to me, from both this writeup and the discussi=
on in both threads, is that "escaped variables" are an unsolvable proble=
m.  If a context variable is "open" (for some generic definition of open=
; that could be a file handle or an unflushed buffer or DB transaction o=
r just a large memory sink), and then a reference to it is saved elsewhe=
re, then when the context block ends, there's two problems that could ha=
ppen:

* If the context block force-closes the variable, then the escaped refer=
ence is no longer valid.  This may or may not cause problems.
* If the context block does not force-close the variable, then we can't =
know that the end of the context block has flushed/completed the process=
.  This may or may not cause problems.

Which one is less of a problem is going to vary with the particular situ=
ation.  I don't think we can make a language-wide statement about which =
is always less problematic.  That means we need to allow individual case=
s to decide for themselves which "leak problem" they want to have.

Which is exactly the benefit of the separation of the Context Manager fr=
om the Context Variable.  The CM can be written to rely on `unset()` clo=
sing the object (risk 2), or to handle closing it itself (risk 1), as th=
e developer determines.

Moreover, it's possible to have two different strategies for the same co=
ntext variable, as either 2 separate Context Managers or one manager wit=
h a constructor parameter.

Suppose the context variable is a `Buffer` instance of some kind, which =
has a `flush()` method and a destructor that calls `flush()`.  Both `For=
cedBufferContext` and `LazyBufferContext` could return the same Buffer c=
lass, but have different approaches to when the flush happens.  That's a=
 level of flexibility that's impossible to achieve if the "exit" logic i=
s on the context variable itself, whether in the destructor or a separat=
e interface method.

Alternatively, `new BufferContext(force: true)` (or whatever) would avoi=
d the need for 2 classes, depending on the specifics of the use case.

To, me, that's a strong argument in favor of the Context Manager approac=
h.