Examples comparing Block Scoped RAII and Context Managers

The Block Scoping RFC and the Context Manager RFC cover a lot of similar
use cases, and a lot of the discussion on both threads has been
explicitly comparing them.

To try to picture better how they compare, I have put together a set of
examples that implement the same code using both features, as well as
some other variations, in this git repo:

https://gitlab.com/imsop/raii-vs-cm

Another suggestion would be to follow the Java try-with-resources
syntax. It does not require a new keyword to be introduced, as with
the Context Manager syntax. Moreover, it aligns with current
try-catch-finally usage already implemented by PHP developers.

try ($transaction = $db->newTransaction()) {
    $db->execute('UPDATE tbl SET cell = :cell', ['cell'=>'value']);
}

I did have a look into that when somebody mentioned it earlier, and I
believe it is almost exactly equivalent to C#'s "using" statement:

• C#: keyword "using", interface "IDisposable", method "Dispose":
  https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/using

• Java: keyword "try", interface "AutoCloseable", method "close":
  https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

The main difference I've spotted is how it combines with other blocks.

In Java, you can use the same block as both try-with-resources and
try-catch:

try ( Something foo = new Something ) {
    blah(foo);
}
catch ( SomeException e ) {
    whatever();
}

In C#, you can instead use a statement version of using within any
existing block:

try {
    using ( Something foo = new Something );
    blah(foo);
}
catch ( SomeException e ) {
    whatever();
}

Both are very similar to RAII, but because both languages use
non-immediate garbage collection, the method is separate from the normal
destructor / finalizer, and other references to the "closed"/"disposed"
object may exist.

At the moment, I haven't included examples inspired by these, because I
thought they would be too similar to the existing RAII examples and
clutter the repo. But if there's a difference someone thinks is worth
highlighting, I can add one in.

Any object that implements TryWithContext can be used with such
syntax. The function returns the exit context operation as callback.

interface TryWithContext {
   public function tryWith(): \Closure;
}

I can't find any reference to this in relation to Java; did you take it
from a different language, or is it your own invention?

Either way, it looks like an interesting variation on the Python-based
enterContext/exitContext. Do you have any thoughts on what it's
advantages or disadvantages would be?

Rather auto-capture I'd suggest explicit complete scope capture, by
using the use keyword without parenthesis.

This is a completely separate discussion I was hoping not to get into.
Although I've personally advocated for "function() use (*) {}" in the
past, I've used "fn() {}" in the "auto-capture" examples because it is
the syntax most often proposed.

It's irrelevant for this example anyway, so I've edited it out below.

For a transaction it might look like this.

class Transaction implements TryWithContext {
    public function tryWith(): \Closure
    {
        $this->db->beginTransaction();
        return function (?\Throwable $e = null) {
            if ($e) {
                $this->db->rollbackTransaction();
                return;
            }

            $this->db->commitTransaction();
        };
    }
}

Looking at this example, it feels like it loses the simplicity of RAII
without gaining the power of Context Managers. In particular, tryWith()
as shown can't return a separate value to be used in the loop, like
beginContext() can in the Python-inspired proposal.

The class would have a separate constructor and tryWith() method, with
no clear distinction. Making the cleanup function anonymous prevents the
user directly calling dispose()/close()/__destruct() out of sequence;
but it doesn't stop the object being used after cleanup, which seems
like a more likely source of errors.

Still, it's interesting to explore these variations to see what we can
learn, so thanks for the suggestion.

--
Rowan Tommins
[IMSoP]