Stream is AutoCloseable, Stream.onClose

[Joe Bowbeer]

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