Additional Collectors

[Brian Goetz]

There are basically three strategies here we could take:

1.  Annoint one direction as the "natural" direction and make the other 
either fit into the general form (as I proposed) or have a modified name 
(as Tim proposes.)  I am fine with either of these.  (There will always 
be those who say "you picked the wrong direction to annoint.)

2.  Lard up both names with a directionality.

3.  Pick totally new names, such as mappedTo and indexedFrom.

Also we want to avoid variant overload.  Right now we have two versions 
each of toMap, toConcurrentMap; a simple (mapping function only) one, 
and a kitchen-sink (mapping function + map ctor + merge function).  This 
was already a compromise to keep the count low.

If we go with my suggestion (keep T->U form, plus add one more general 
form) that is 4 new methods.  If we decide to have forms for all three 
forms, that's 8 new methods.

I think if we do
   Map<T,U> toMap(T->U)
and
   Map<K,U> toMap(T->K, T->U)

we can call them both toMap and people will get it.

On 4/3/2013 1:49 PM, Tim Peierls wrote:
> On Wed, Apr 3, 2013 at 1:27 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     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>.
>
>
> The second form (Stream<T> and T->K producing Map<K, T>) could be called
> "indexing", so toIndexMap or toIndex would seem appropriate. I don't
> have a sense of a natural name for the third form. toMap still seems
> good for the first form.
>
>     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:
>
>        toMap(T->U) // first version
>        toMap(T->K, T->U) // third version
>
>     and leave the second version out, since the third version can easily
>     simulate the second?
>
>
> Maybe, but I like the thought of toIndex or something like that.
>
> --tim
>