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

Joshua Bloch jjb at google.com
Sat Mar 21 11:01:52 PDT 2009

Mark,

On Sat, Mar 21, 2009 at 9:37 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

Hi Josh,

2009/3/21 Joshua Bloch <jjb at google.com>

What if you have an interface that extends an interface that extends the magic marker? There should be nothing wrong with that. While there may be some easy way to specify this (and give it reasonable semantics) it isn't jumping out at me. If anyone has any clever ideas along these lines, I'd love to know.

I'm probably missing the point, but doesn't the JLS generally use the phrase 'is a subtype of' to describe this kind of relationship?

I don't think I did a good job of explaining the problem. Consider this:

interface Closeable extends MagicMarker { void close(); }

interface Foo extends Closeable { // Must be OK for ARM // Lots of methods }

class bar implements Foo { // Must be OK for ARM // Lots of methods }

interface Baz extends Foo { // // No new methods }

class Qux Implements Foo, Baz { // Probably OK for Arm ]

interface Disposable extends MagicMarker { public void dispose(); }

class Nope implements Closeable, Disposeable { // Probably not OK for ARM }

The problem with Nope is that it contains two "magic methods" (sole parameterless method in an interface that directly extends MagicMarker). Is it sufficient to say that a class must have one and only one magic method to make it eligible for automatic resource management? Is it practical to implement this in the compiler? I dunno.

     Josh

      Josh

More information about the coin-dev mailing list