Stream is AutoCloseable, Stream.onClose

[Remi Forax]

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