Function level try recourse directives.

[Red IO]

I agree that it seems like a minor improvement to remove 1 level if
nesting. But it removes 1 level of nesting per individualy managed recourse
(taking into consideration that you can group resources in 1 try block).
I would argue that it isn't really a completely new feature but an
ergonomic addition to the existing of try resource. It would be handled
completely by the preprocessor (or however syntactic sugar is implemented).
Regarding the coupling of object and resource scope. I would argue that
resource scopes naturally align with method scopes since the single
responsibility of the method would be something regarding the closable
resource.
Regarding refactoring I don't think tools would have a hard time
refactoring:

void foo() {
try (var foo = new Foo()) {
foo.bar();
}
}
To:
void foo() {
try (var foo = new Foo());
foo.bar();
}
And back. This refactoring can also often easily done by hand. Regarding
methd extraction the tool would simply need to unwind (turn the lower
example into the one above it). This is always a trivial refactoring since
the implicit scope of the foo variable lasts from the try block to the end
of the method. Even if you have multiple resources:

void foo() {
try (var foo = new Foo());
try (var foo2 = new Foo());
foo.bar(foo2);
}
It is trivially refactored to:

void foo() {
try (var foo = new Foo()) {
try (var foo2 = new Foo()) {
foo.bar(foo2);
}
}
}

If you look at this simple example alone without any logic like an if
statement or a loop the amount of nesting really makes things hard to read.
In contrary the version with the scopeless try resource still highlights
the special treatment of the object while looking similar to a normal
object creation the whole thing really is.
The implementation effort and risk of the feature is low while the amount
of clarity it adds is high.
There is also a data that shows the impact of the feature since it already
exists in c# which is synthatically nearly equivalent to java.
I also don't think it makes the language harder to learn or to understand.
For people who already know the try with resources feature only need to
"learn" that you can now use try resource with a method level scope. If you
are new to try with resources you learn that you can automatically manage
closable resources either at method level or with its own confined scope.

The c# reference site of the feature:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-statement


On Wed, Dec 28, 2022, 18:16 Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> > On Dec 28, 2022, at 12:06 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> >> I think there where many valid points against it mentioned. But I
> disagree with your scope thesis. The "open try resource" is not meant to be
> used like this:
> >> void foo() {
> >>      ..
> >>      {
> >>              try (..);
> >>              ..
> >>      }
> >>      ..
> >> }
> >
> > Which is what I understand you mean by opening a scope just for the
> scope itself. It is meant primarily for use cases where your resource live
> the lifetime of the function, which is pretty common in well refractored
> code.
>
> There was some sort of editing error here, the above sentence was part of
> Red’s mail, not my reply.  My reply begins here:
>
> > What you are advocating for is something like Golang’s `defer`
> statement, which queues up cleanup operations to run at function exit.
> >
> > But, the `defer` mechanism is a weak bit of language design; it forces
> developers to align method boundaries with resource management boundaries,
> even when the two don’t agree.  Yes, the two coincide often enough to make
> it seem harmless and even clever, but such couplings often end up being
> impediments to refactoring and the source of subtle bugs.  (For example, an
> “extract method” refactor may change the order in which resources are
> released.). Ultimately, it has many of the same deficiencies as global
> static state or nonlocal control flow — it interferes with modular
> reasoning.  Adding more of this into the language isn’t necessarily
> helpful.
> >
> >
> >> Which is exactly what the current existing try resource is. The
> motivation of feature is to remove redundant nesting.
> >
> > I think this is the root of the problem.  This is not a very strong
> motivation for introducing a new and different form of scoping into the
> language.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221228/1c218df3/attachment.htm>