Proposal: Automatic Resource Management

Bob Lee crazybob at crazybob.org
Fri Mar 6 14:54:59 PST 2009


Mark,

On Fri, Mar 6, 2009 at 1:40 PM, Mark Mahieu <markmahieu at googlemail.com>wrote:

> On 6 Mar 2009, at 21:11, Bob Lee wrote:
>
>>  Does anyone have real world
>> examples where adapting an API to work with Disposable or Resource would
>> be
>> so egregious as to justify the complexity inherent in the finally
>> modifier?
>> Please limit examples to only those that you would actually want to use
>> with
>> this language construct.
>>
>
> Well, that is what I've been doing.


Let me rephrase. I'm suggesting that we shouldn't try to cater to each and
every existing use case--it's not worth it. I didn't recommend supporting
"Disposable.dispose()" because it works seamlessly for some existing use
cases. It's just a coincidence that its signature matches. I suggested
"dispose()" because it sounds more general than "close()" and has wider
applicability for future APIs. We could just as easily use "release", but we
should just pick one (in addition to close()). We have to draw the line
somewhere, and less is more. Heck, maybe we should just support close()!

As someone who is partially responsible for the API of the most ill-fitting
use case (HttpResponse), I'm saying I'd rather keep the language simple and
adapt the API. For other existing APIs, we can add close() or dispose() or
introduce adapter classes. It appears the cases where this is necessary are
relatively rare though.

This reminds me a bit of foreach and java.util.Enumeration. Does it bother
you much that foreach foreach doesn't support Enumeration? It doesn't me.
I'm glad that foreach is simpler and easier to learn. I think it's a good
thing that foreach has encouraged API designers to converge on supporting
Iterable (as opposed to Enumeration and Iterator directly). In that same
vein, if we take the interface-based approach, "try resource" would
encourage API designer's to converge on one or two interfaces, something
that would enable further APIs that deal with Disposables (like Neal
suggested).

As an aside, if I were writing a library that deals with Disposables, it
would not bother me that dispose() throws Exception. In general, I'm either
going to wrap the exception and rethrow it or log it somehow.

Bob



More information about the coin-dev mailing list