Stream is AutoCloseable, Stream.onClose
joe.bowbeer at gmail.com
Fri Jun 21 10:19:42 PDT 2013
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.
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()
> 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
> If there were an alternative that didn't completely suck, I'd be open to
> that. (So far, though, no such alternative has emerged.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts