Feedback and comments on ARM proposal (original) (raw)

Howard Lovatt howard.lovatt at iee.org
Wed Mar 18 01:02:25 PDT 2009

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.

More information about the coin-dev mailing list