Proposal: Automatic Resource Management

[Neal Gafter]

See http://www.two-sdg.demon.co.uk/curbralan/papers/AnotherTaleOfTwoPatterns.pdf
for a discussion of the pattern.  With closures in the language, you'd
get the possibility of more flexible resource management than is
provided by this proposal.  For example, you could write APIs to
provide convenient support for the use of
java.util.concurrent.locks.Lock,
java.util.concurrent.locks.ReadWriteLock, transactions that can either
be committed or rolled back, etc, without requiring the language
commit itself to a single pattern.  Worse: a single pattern that we
would have to get right in the next ~3 months.  These and other
resource management patterns in use today simply don't fit into the
mold of this proposal.  That is a warning sign that a language
construct directly encoding the pattern is inappropriate.

-Neal

On Tue, Mar 3, 2009 at 8:32 PM, Bob Lee <crazybob at crazybob.org> wrote:
> Neal, it might help if you cited some specific examples. I've never
> personally suffered from Closeable's exception signature, and I can't
> imagine suffering from that of Disposable. I have suffered from the fact
> that no one seems to close resources correctly, and I'd love to have this
> feature whether we get closures one day or not.
>
> Bob
>
> On Tue, Mar 3, 2009 at 8:19 PM, Neal Gafter <neal at gafter.com> wrote:
>>
>> I think you're missing the point, Josh.  People do this today with
>> Closeable, because that's the closest interface available that could
>> be used to perform this function, but clients suffer from its
>> exception signature.  Disposable is better in one way - it would be
>> retrofitted onto more classes - but much worse in its exception
>> signature.  You're saying that there's no pain because you can't use
>> it as a parameter type.  I'm saying that is the cause of the pain.
>> The language construct that you're proposing does not supplant this
>> technique of resource management, but the APIs you're proposing to go
>> with it interfere with the technique.
>
>