Proposal: Automatic Resource Management (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Sun Mar 8 01:00:37 PST 2009

We're veering waaay offtopic here; the ARM proposal does not address
locks. Period. Would everyone be happy if this was added in the 'major
disadvantages' section?

If locks are truly deemed crucial, or the consensus is that,
eventhough evidently ARM-as-is can't do locks, people will try anyway
and the resulting confusion must be avoided, I suggest that the ARM
proposal is updated to do the right thing when an expression of type
Lock shows up in a try ( lockShowsUpHere ) { code} block. Someone else
proposed this before and I can't see any downside to this. It would be
bad if, for every release, a bunch more types get special uniquely
defined semantics in relation to the ARM expression, but that seems
very unlikely. Nobody else has named a use-case that doesn't work in
vanilla ARM yet seems likely to be abused, other than Lock, IIRC.

--Reinier Zwitserloot

On Mar 8, 2009, at 09:03, Peter Mount wrote:

On Sun, Mar 8, 2009 at 7:58 AM, Jeremy Manson <jeremy.manson at gmail.com>wrote:

I am aware Lock is an interface. You wouldn't actually change the Lock interface, you would change the classes. Just as they retrofit Iterable everywhere. That's why I put "class Lock" there; perhaps it would have been clearer if it said "class MyLock". What about when someone just references the lock as Lock rather than the implementing class? Javac won't be able to determine that the lock implements Disposable so in that case it will fail..

Jeremy On Sat, Mar 7, 2009 at 10:23 AM, Stephen Colebourne <jodastephen at gmail.com> wrote: Jeremy Manson wrote: The "right" fix, if we want to support this pattern, is to allow the try resource statement to accept expressions that return Disposables, and to retrofit the relevant lock APIs with disposables and lock methods that return this: class Lock implements Disposable { public Lock dlock() { return this; } @Override public void dispose() { unlock(); } } Lock is an interface. No changes are possible. Stephen

-- Peter Mount e: peter at retep.org.uk w: http://retep.org Jabber/GTalk: peter at retep.org MSN: retep207 at hotmail.com

More information about the coin-dev mailing list