Cancelable streams (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Jan 9 13:19:58 PST 2013

On 01/09/2013 09:18 PM, Brian Goetz wrote:

That's a different feature, and one that is more complex to spec (and this complexity is what almost pushed us to just give up on cancelation.)

The complexity comes from the parallel case, in the interaction with encounter order. Users might do forEachUntil(e -> e.equals("3")) on a stream of 1, 2, 3, 4, 5, 6 and be very surprised that on completion, elements 1, 3, and 6 have been processed. They'll wonder "what happened to 2, it was before 3", and similarly wonder "why 6, it is after 3."

given that he asks for something parallel, he gets what he asks, no ?

Rémi

On 1/9/2013 2:56 PM, Remi Forax wrote: On 01/09/2013 08:44 PM, Brian Goetz wrote: I've pushed a stream op "forEachUntil(Block, BooleanSupplier)". After offline discussion with Doug, this seemed to be an acceptable alternative to having no cancelation support at all.

Sorry, I've forgotten to answer. While I agree with the concept, I think forEachUntil has the wrong signature, the issue I see is that some time you want to stop depending on a value which is a property of an element, but here the BooleanSupplier doesn't have access to the current element. I would prefer void forEachUntil(Predicate<? super T> condition) so one can write stream.forEachUntil(e -> e.accuracy <= 0.5) cheers, Rémi

More information about the lambda-libs-spec-observers mailing list