Stream is AutoCloseable, Stream.onClose
forax at univ-mlv.fr
Fri Jun 21 10:28:03 PDT 2013
onClose takes a callback and not the resource,
is valid in my opinion but not
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,
> 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
> <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
> for method names in callback interfaces. It is the prevalent
> currently. So I'd expect onClose() to be the method that is
> 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 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.)
More information about the lambda-libs-spec-observers