Proposal: Automatic Resource Management

[Reinier Zwitserloot]

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
>