Coin Considerations (original) (raw)

Neal Gafter neal at gafter.com
Sat Mar 14 16:39:01 PDT 2009

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.

More information about the coin-dev mailing list