Feedback and comments on ARM proposal - resend

[Howard Lovatt]

Hi Neal & Joshua,

I probably need to supply more info, see text below.

2009/3/15 Neal Gafter <neal at gafter.com>:
> On Sat, Mar 14, 2009 at 7:55 PM, Howard Lovatt <howard.lovatt at iee.org> wrote:
>> Instead of writing:
>>
>> try ( Resource r = new Resource() ) {
>>  r.doSomething();
>> }
>>
>> You would write:
>>
>> final Resource r = new Resource();
>> r.doSomething();
>
> I think this requires something like a new modifier on the local
> variable declaration.  Without a distinguished syntax, I don't see how
> to distinguish this from a normal local variable declaration.

Joshua Bloch wrote:

> There is room for disagreement here.  We discussed this extensively at Google when I drafted the proposal, and
> we ended up eschewing a declaration-based approach because there was general agreement that it was much
> less Java-like to imbue the closing bracket with such "magical powers."

Maybe then in response to both your points some syntax like:

  AutoResource ar = autoresource MyResource();
  ar.doSomething();

and for other blocks, e.g. foreach loops:

  for ( String line : autoresource IterableFile(...) ) { ... }

Is best. Note keyword autoresource and that keyword autoresource would
mean allocation of a new resource and would replace new. The resource
is disposed of at the end of the block it is declared in, there is no
requirement for the variable to be final or even for an explicit
variable. It is an error to attempt to create an AutoResource using
new, you must use autoresource (this catches the mistake new
MyResource() which may be common at first).

As an aside to Joshua, I liken not having an explicit set of braces
for resource management like automatic garbage collection, create and
forget, and hence Java like. However the behaviour of auto-disposing
is also C++ destructor like, so I can see other peoples point of view
on this. Both approaches would be an improvement on what we currently
have. My preference is not to have braces because I prefer the syntax,
particularly for existing block structures like the foreach loop.

Neal gafter wrote:

>> This is so much more Java like than the block construct, why not do
>> this instead of the block construct (note it would be an error not to
>> declare the resource final). r.dispose() is called at the end of the
>> enclosing block, provided that r is not null, when r goes out of
>> scope, which is probably what you want anyway (you can insert an
>> existing {} block if you have to control lifetime). Also, why not make
>> the dispose method exception free, realistically what can a user of an
>> API do if dispose throws an exception?
>
> If it's not final, what happens when the variable is reassigned?

See comment above - have removed final requirement in response to your concern.

> Without allowing checked exceptions on the resource release, I don't
> see how to retrofit this onto the primary use-case, Closeable.

I would propose AutoResource to be:

interface AutoResource { void autoDispose(); }

And the 'contract' for an AutoResource to be something that is auto
opened, either when created or first used, that is to be automatically
closed, that issues exceptions if the resource is used after it is
closed (or that the JavaDoc notes that this resource quietly ignores
usage after closure), that is tolerant, without complaint, of multiple
calls to autoDispose, and that autoDispose can optionally throw an
unchecked exception to report a closure problem (typically this error
will be logged and the program will terminate its current operation or
terminate completely).

Then new interfaces and existing and new classes can extend/implement
AuroResource. The purpose of picking autoDispose as the method name
and autoresource as the keyword is to make name clashes unlikely. I am
proposing that this should be a deliberate retrofit, not a consequence
of the behaviour of an existing interface changing. That way someone
needs to consciously decide they want AutoResource and are in effect
saying, by implementing AutoResource, that they agree to its contract
(as outlined above).

What do you think?

Howard.