Proposal: Automatic Resource Management
markmahieu at googlemail.com
Fri Mar 6 15:27:05 PST 2009
Right - I do agree with your points in general, and there are
certainly aspects of the interface approach that I like very much.
All I'm suggesting is that using a modifier instead is a possible
alternative that I personally think is worth investigating. I
certainly don't think it's clearly better or anything like that; I
don't see enough evidence either way at this point, and as I said
when I suggested it, I can think of a number of questions that would
Please don't take the fact that I've been looking for problematic
APIs, or suggesting alternatives, as a negative; my intention is to
provide constructive points (critical or otherwise) which are of
value to the discussion and the proposal.
In particular, I think that documenting specific examples of
problematic APIs adds to the proposal rather than detracts from it.
On 6 Mar 2009, at 22:54, Bob Lee wrote:
> 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
> 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
> 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.
More information about the coin-dev