Coin Considerations

[Neal Gafter]

Florian-

As an alternative formulation of resource management, I like that this
proposal doesn't mix up the new construct with an already existing
control construct.  I have two issues with this alternative
formulation of ARM blocks.  First, it allows reassigning the variable
referencing the resource.  That means you might end up closing a
different resource than the one you opened.  The other issue is its
dependence on annotations as a way to avoid adding modifiers.
Annotations are supposed to be just that: annotations of the code.
They should not modify the behavior of language primitives.

Regards,
Neal

On Sat, Mar 14, 2009 at 4:20 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Reinier Zwitserloot:
>
>> Here's my list (* means: Definitely 'believe' in it, just need the
>> time, and '-' means: Not entirely sure it can be made simple enough
>> for coin / is a good idea in the first place):
>
> I would like to see:
>
>  o transient modifier on local variables
>
>    Basically,
>
>       {
>         transient SomeClass foo = getFoo();
>         doSomething(foo);
>       }
>
>   is translated to:
>
>       {
>         transient SomeClass foo = getFoo();
>         try {
>           doSomething(foo);
>         } finally {
>           if (foo != null) {
>             foo.cleanup();
>           }
>         }
>       }
>
>    were SomeClass#cleanup() is the single method in class SomeClass
>    which carries a @Cleanup annotation.
>
>    The "!= null" part is there to make it possible to signal to the
>    cleanup handler that the object has changed ownership.  Assignment
>    to the variable does not trigger cleanup, cleanup only happens at
>    scope exit.
>
>    Annotation-controlled overlading is used instead of an interface
>    because the existing cleanup routines have a myriad of different
>    names and declare different checked exceptions, too.  If there are
>    multiple @Cleanup methods for a type, a warning should be issued
>    if this happens through inheritance (old code which needs to be
>    ported), or an error if there are multiple such methods declared
>    in the same type (erroneous new code).  In both cases, if such a
>    type is used in a transient local variable declaration, the
>    declaration is rejected.
>
>    Syntactically, this extensions blends well with type inference for
>    local variables.  However, similar to other forms of compile-time
>    overloading, removing type declarations will change invoked
>    methods in a few corner cases.
>
>    The choice of the transient keyword means that the same syntax
>    cannot be used for generating cleanup methods for classes.  It is
>    not clear to me how to generate code for such classes in the
>    presence of inheritance and exceptions, so I don't think this is a
>    significant problem. (This problem does not arise in the local
>    variables case because there is a clear nesting of scopes.)
>
>    My hope is that such an extension eventually leads to code which
>    has got fewer resource leaks, but is as succinct and as easy to
>    read as code which (improperly) relies on garbage collection.