Interesting thought, Henry. Given your explanation, I perhaps garner the semantics of AutoCloseable should be loosen to equal what MayHoldCloseableResource is. Rather than say AutoCloseable is a resource that must be closed, simply say it's a resource that can be closed. Then MayHoldCloseableResource can disappear.
On Thu, Jul 11, 2013 at 3:52 PM, Henry Jen <henry....@oracle.com> wrote: > 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 > -- Cheers, Paul
