Into

[Remi Forax]

On 12/26/2012 08:11 PM, Brian Goetz wrote:
>>> Since we can't read the user's mind about whether they care about
>>> encounter order or not (e.g., they may use a List because there's no
>>> Multiset implementation handy), I think we need to provide ways of
>>> aggregating that let the user explicitly choose between
>>> order-preserving aggregation and concurrent aggregation.  I think
>>> having the word "concurrent" in the code somewhere isn't a bad clue.
>>
>> This defeat one important purpose of the Stream API which is to be
>> parallel/sequential agnostic from the user POV.
>
> Only to the extent that reality forces us to.  The user has to declare 
> whether they care about encounter order vs arrival order, or 
> (equivalently) whether their reducers are associative or commutative. 
> The user *does* have to understand this, otherwise we lose many of the 
> benefits of parallelism by being forced to make bad assumptions.

you can hide that by asking what the user want as result.

>
>> Here having a toList() that take care about concurrency if needed is 
>> very appealing.
>
> Only if the cost of this is not that performance sucks in surprising 
> ways.  The performance of into() sucks in surprising ways.
>

into() sucks because it's currently implemented as sequential().into().
toList() doesn't require that and into() can be specified to avoid that.

Rémi