Proposal: Automatic Resource Management

[Mark Mahieu]

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  
need answering.

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.

Best regards,

Mark


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  
> 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