Stream is AutoCloseable, Stream.onClose

[Henry Jen]

I am not sure I understand, isn't what proposed here for onClose() is
similar to register a callback which is to be invoked when
Stream.close() is called?

Cheers,
Henry


On 06/20/2013 11:50 AM, Joe Bowbeer wrote:
> Anything reasonably close without an "on" prefix would be better. Given the
> prevalent onNaming style in many, many currently used frameworks, onClose
> just looks wrong, both in its use and in Stream's list of methods.
> On Jun 20, 2013 11:18 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
> 
>> FWIW, the closest analogue to "onClose" in the current API is "parallel",
>> which modifies execution characteristics of the current stream (whether it
>> does this mutatively or functionally is a detail).
>>
>> Perhaps a good analogy would be: what would you call a "register a close
>> hook" method on a builder object?  Because Stream is kind of like a
>> builder.  I am not sure the onClose(closeAction) is all that confusing in
>> the context of a builder; its not a method declaration, and almost no user
>> will ever implement Stream directly, so I'm not sure the confusion is all
>> that bad?
>>
>> On 6/20/2013 2:10 PM, Joe Bowbeer wrote:
>>
>>> I like the benefits, though I think the onClose name is confusing.
>>>
>>> In many frameworks, the onError/onExit/onEvent naming style is reserved
>>> for method names in callback interfaces.  It is the prevalent convention
>>> currently.  So I'd expect onClose() to be the method that is called-back
>>> upon closing.
>>>
>>> The method name that is needed for this wrapping purpose should be
>>> something more imperative, possibly mentioning its function as a "close"
>>> guard.
>>>
>>> Some ideas below:
>>>
>>> .autoclose(ac)
>>> .autoclosing(ac)
>>>
>>> .closeableStream(ac)
>>>