Encounter order

Brian Goetz brian.goetz at oracle.com
Fri Oct 26 06:04:23 PDT 2012


Its the same problem of sensibility that we get with ordinary reduce. 
If we can only assume the reducer is associative, and we see that the 
input source structurally has an encounter order, then reordering the 
elements could result in the wrong answer.  (i.e., it stands to reason 
that stream.reduce(r) should produce the same result as 
stream.reduceBy(e -> 1, r).get(1)).

On 10/26/2012 8:55 AM, Andrey Breslav wrote:
> People don't expect ordering of the *keys*, and that's fine.  What I
>>>> was talking about was ordering of the values, since the Map returned
>>>> is a Map<K, Collection<V>>.
>>> Your reduceBy() looked like this:
>>>
>>> <U, W> Map<U, W> reduceBy(...)
>>>
>>> no collections anywhere. Was that a mistake?
>>
>> groupBy returns a Map<K,Collection<T>>.
>>
>> reduceBy returns a Map<K,W>, because instead of accumulating elements
>> in a K bucket and sticking them in a collection, we reduce all the
>> elements in the K bucket.
>>
>> For example:
>>
>>   Map<Author, Document> longestDocByAuthor
>>     = docs.reduceBy(Document::getAuthor,
>>                     (d1, d2) -> (d1.length() > d2.length() ? d1 : d2));
>>
> Yes. And my point was that thus no ordering considerations are
> applicable to the result of reduceBy. Or am I missing something?


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