Additional Collectors

[Ali Ebrahimi]

Hi brian,
I have concerns about toMap method and this may result in unexpected and
unpredictable results in user program, and this method only have mean for
unique collections (Set) and streams (resulted for Stream.distinct).
Consider this example:

class Entity{
     int id;   //key field
     String name;
 // override equals and hashcode
....
}

Entity foo = new Entity(1, "Foo");
Entity bar = new Entity(1, "Bar");
List<Entity> entities = list(new Entity(0, "Some"),foo,..., bar,...)

Map<Entity,String> entitymap=entities.stream().collect(ToMap(e -> e.name));

what is result of entitymap.get(foo)? "Foo" or "Bar"

Map<Entity,String> entitymap2=entities.parallelStream().collect(ToMap(e ->
e.name));

what is result of entitymap2.get(foo)? "Foo" or "Bar"

Suggestion1: get rid of ToMap
Suggestion 2: May be we need consider adding subclass UniqueStream with
additional method toMap and change return type of  Stream.distinct and
Set.stream to UniqueStream.

What do you think?

Ali Ebrahimi





On Wed, Apr 3, 2013 at 9:57 PM, Brian Goetz <brian.goetz at oracle.com> 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:
>
>   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?
>
>