Proposal: Automatic Resource Management
Jeremy Manson
jeremy.manson at gmail.com
Wed Mar 4 00:03:51 PST 2009
On Tue, Mar 3, 2009 at 11:56 PM, Neal Gafter <neal at gafter.com> wrote:
> On Tue, Mar 3, 2009 at 11:49 PM, Jeremy Manson <jeremy.manson at gmail.com> wrote:
>> As a side note to this conversation, directed at any people who will
>> think you can't have this feature with this proposal, regardless of
>> your feelings about the particular merits of accomplishing the same
>> thing with closures, there *is* a way to handle this case:
>>
>> try (LockDisposer l = new LockDisposer(lock.readLock())) {
>> clientCount++;
>> }
>>
>> try (LockDisposer l = new LockDisposer(lock.writeLock())) {
>> return field.getValue();
>> }
>
> Yow. I think the cure might be worse than the disease.
That's why I suggested changing try() so that it took an expression.
The second version was, I think you will admit, much cleaner.
>> I suspect a LOT of people will be doing something similar to this hack
>> if this proposal is adopted. To make it much cleaner, you could first
>> adjust this proposal so that the try statement can take an expression
>> that returns a Disposable, and then you could adjust the Lock classes
>> so that a) lock() returns this and b) they implement Disposable, at
>> which point you could have:
>
> You can't make such changes to existing interfaces without breaking
> existing code. Changing the signature of lock() breaks existing
> callers, and adding a close() method (to implement Disposable) breaks
> existing implementations.
I'm probably being typically dumb, but I'm not sure how adding a
method breaks anything. You don't *have* to change the signature of
lock -- just add a new method (call it "disposeLock") that has the
required semantics:
try (lock.readLock().disposeLock()) {
clientCount++;
}
try (lock.writeLock().disposeLock()) {
return field.getValue();
}
Jeremy
More information about the coin-dev
mailing list