Stream is AutoCloseable, Stream.onClose
brian.goetz at oracle.com
Fri Jun 21 10:36:51 PDT 2013
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,
> 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
>> 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
>> 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-experts