Additional Collectors

[Remi Forax]

On 04/03/2013 07:27 PM, Brian Goetz wrote:
> There's been some feedback on lambda-dev and from the recent Lambda 
> Hack Day on Collectors.  There were two big categories:
>
> 1.  Need more / better docs.
>
> 2.  We want some more collectors.
>
> The first is obvious and we've been working on those.  Here are some 
> suggestions for simple additions to the Collector set.
>
>  - count() (and possibly sum, min, max)
>
> These are straighforward analogues of the specialized stream methods; 
> they serve as a "gentle on ramp"  to understanding reduction.
>
> People also expressed concern that the "toMap()" (nee mappedTo, 
> joiningWith) is not flexible enough.  As a reminder, what toMap does 
> is take a Stream<T> and a function T->U and produces a Map<T,U>.  Some 
> people call this "backwards"; they would rather have something that 
> takes a Stream<T> and function T->K and produces a Map<K,T>.  And 
> others would rather have something that takes two functions T->K and 
> T->U and produces a Map<K,U>.
>
> All of these are useful enough.  The question is how to fit them into 
> the API.  I think the name "toMap" is a bit of a challenge, since 
> there are several "modes" and not all of them can be easily handled by 
> overloads.  Maybe:

better if you rename U to V

>
>   toMap(T->V) // first version

produces a Map<T,V>

> toMap(T->K, T->V) // third version

produces a Map<K,V>.

why toMap(T -> V) is not toMap(T -> T, T, -> V) ?
in that case, we only need one toMap.

>
> and leave the second version out, since the third version can easily 
> simulate the second?
>

cheers,
Rémi