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]
