toMap options

[Brian Goetz]

Note also that the separation of Collector from Stream allows you to 
write your own, and allows Guava to publish properly typed collectors 
for, say, their implementation of Multimap.

The pedagogical question remains, though -- how to spread these examples 
throughout Javadoc so people are exposed to the idioms.

On 4/9/2013 8:23 PM, Tim Peierls wrote:
> Easy if you know how! At any rate, it's doable, and this might serve as
> an example for groupingBy.
>
> --tim
>
> On Tue, Apr 9, 2013 at 7:51 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     So you've got a Stream<T>, and you want a Map<K, Collection<V>>, and
>     you've got a T->K called "f" and a T->V called "g".  Easy:
>
>        Map<K, Collection<V>> multiMap
>           stream.collect(groupingBy(f, mapping(g, toList()));
>
>
>     On 4/9/2013 7:48 PM, Tim Peierls wrote:
>
>         No objection, but now it makes me wonder: How do you get the
>         effect of
>         toMultimap(T->K, T->V)? In other words, how would you get a Map<K,
>         Collection<V>> from a Stream<T> given T->K and T->V mappings?
>
>         --tim
>
>         On Tue, Apr 9, 2013 at 7:33 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>         <mailto:brian.goetz at oracle.com
>         <mailto:brian.goetz at oracle.com>__>> wrote:
>
>              I'm good with #3.  Any objections?
>
>
>              On 4/9/2013 7:28 PM, Sam Pullara wrote:
>
>                  I like version 3 as well.
>
>                  Sam
>
>                  On Apr 9, 2013, at 2:29 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>                  <mailto:brian.goetz at oracle.com
>         <mailto:brian.goetz at oracle.com>__>> wrote:
>
>                      Currently we have:
>
>                           Collector<T, Map<T,U>>
>                           toMap(Function<? super T, ? extends U> mapper)
>
>                      and
>
>                           <T, U, M extends Map<T, U>>
>                           Collector<T, M>
>                           toMap(Function<? super T, ? extends U> mapper,
>                                 Supplier<M> mapSupplier,
>                                 BinaryOperator<U> mergeFunction)
>
>                      (plus concurrent versions of both of these.)  The
>         former is
>                      just sugar for:
>
>                         toMap(mapper, HashMap::new, throwingMerger())
>
>                      (We have predefined merge functions for
>         throw-on-duplicates,
>                      first-wins, and last-wins, called throwingMerger,
>                      firstWinsMerger, and lastWinsMerger.)
>
>                      As has been noted, we do not yet serve the use case of
>                      creating a map where the stream elements are the
>         values of
>                      the map instead of the keys of the map.  Options for
>                      addressing this are:
>
>                      1.  Leave toMap as is, add toIndexedMap (or toKeyedMap)
>                      variants.
>
>                      2.  Leave toMap as is, add a two-function version
>         of toMap:
>
>                           <T,K,U>
>                           Collector<T, Map<K,U>>
>                           toMap(Function<T, K> keyMapper,
>                                 Function<T, U> valueMapper)
>
>                      in which case the regular toMap becomes sugar for
>
>                           toMap(Function.identity(), mapper)
>
>                      3.  Get rid of the current form of toMap, and just
>         have the
>                      two-function form as in (2).
>
>                      4.  Break free of the toMap naming (recall that until
>                      recently this was called mappedTo, and prior to that,
>                      joiningWith), and have two versions: mappedTo and
>                      mappedFrom.  This is explicit, but also doesn't
>         address the
>                      use case where both key and value are functions of the
>                      stream elements.
>
>                      Others?
>
>
>
>