Stream is AutoCloseable, Stream.onClose

[Brian Goetz]

OK, I buy that this is an improvement.

On 6/21/2013 1:28 PM, Remi Forax wrote:
> onClose takes a callback and not the resource,
> so
>    stream.onClose(resource::close)
> is valid in my opinion but not
>    stream.onClose(resource)
>
> Rémi
>
> On 06/21/2013 07:19 PM, Joe Bowbeer wrote:
>>
>> Your explanation makes little sense to me. I've never seen onEvent
>> methods used in a fluent style, except perhaps in a builder pattern,
>> and even then the names are usually clearer, for example,
>> registerOnCloseHandler.
>>
>> The extent to which our objection is overblown is hard to gauge but I
>> think plenty of better alternatives exist.
>>
>> Joe
>>
>> On Jun 21, 2013 9:26 AM, "Brian Goetz" <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> 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.
>>
>>
>>     After reflection, I think this concern, while valid, may be
>> overblown.
>>
>>     In a functional system, it is totally natural to treat "onXxx(f)"
>>     as "run function f on Xxx".  For example:
>>
>>       new Window()
>>         .onClose(closeFn)
>>         .onMinimize(minimizeFn)
>>         .onClick(clickFn);
>>
>>     I think if someone saw this code, they would not be confused at
>>     all; its very clear what is going on.
>>
>>     In a purely functional system, all the onXxx would take a
>>     function.  In a purely OO system, all the onXxx would be methods
>>     that get called at the appropriate time.  Confusion would come
>>     only if we mixed the two "too much".  Its not obvious what the
>>     granularity at which it becomes too much, but "within the same
>>     abstraction" might be a reasonable place to draw that line.
>>
>>     If there were an alternative that didn't completely suck, I'd be
>>     open to that.  (So far, though, no such alternative has emerged.)
>>
>