On 07/11/2013 01:22 PM, Paul Benedict wrote: > Paul S.'s said the "negative" of using AutoCloseable is "it is no longer > clear whether a stream should be closed or not" (6/20). That's true > because the semantics of AutoCloseable indicates you have a resource > that requires closing. >
I believe that the negative of 'whether a stream should be closeable or not' is by eliminating CloseableStream vs. Stream, not the choice of AutoCloseable. > However, the choice to make MayHoldCloseableResource a sub-interface of > AutoClosable should be resisted. It's an inverted design. The Liskov > /substitution principle /says that sub-interfaces can't loosen the > contracts of their superinterface. If anything, AutoCloseable should be > subclass of this new interface, which MIGHT hold a resource that > requires closing. The current choice is just plainly backwards. > The reason to be subclass of AutoCloseable is Try-With-Resource construct. AutoCloseable is not a fit mainly because close() method throws Exception, and as you suggested, the "impression"(not explicit expressed, look at other AutoCloseable where close() is not required) that AutoCloseable means something should be closed. While I agree your argument, I sort of thinking it's more Closeable vs MayHoldCloseableResource, where AutoCloseable is a indicator that such resource can be closed with TWR. Cheers, Henry
