Cancelable streams

[Remi Forax]

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