Collector / Collectors

[Brian Goetz]

Returning to this...

We tried the collector.andThen() approach.  People liked the API, but we 
ran afoul of type inference issues.  I think the remaining option is a 
combinator:

   collector+finisher -> collector

but the previously suggested name (finishing) had an "inside out" feel. 
  But, I think a slight name tweak will do the job:

      groupingBy(Person::getCity,
                 collectingAndThen(maxBy(comparing(Person::getHeight)),
                                   Optional::get)));

to suggest what is going on.

On 6/26/2013 2:26 PM, Brian Goetz wrote:
>
> 2.  Making the one-arg reducing(), and minBy/maxBy, return Optional
> means that queries like "tallest person by city" end up with Optional in
> the value:
>
>    Map<City, Optional<Person>> m
>      = people.collect(groupingBy(Person::getCity,
>                                  maxBy(comparing(Person::getHeight)));
>
> Which is doubly bad because the optionals here will *always* be present,
> since otherwise there'd be no associated key.
>
> I can see a few ways to address this:
>   - Provide non-optional versions of minBy/maxBy/reducing, which would
> probably have to return null for "no elements".
>   - Provide a way to add a finisher to a Collector, which is more
> general (and could be used, say, to turn toList() into something that
> always collects to an immutable list.)
>
> The latter could, in turn, be done in one of two ways:
>
>   - Add a andThen(f) method to Collector.  Then the above would read:
>
>     groupingBy(Person::getCity,
>                maxBy(comparing(Person::getHeight))
>                  .andThen(Optional::get))
>
>   - Add a combinator:
>
>     groupingBy(Person::getCity,
>                finishing(maxBy(comparing(Person::getHeight)),
>                          Optional::get)));
>
> I prefer the former because it reads better in usage; using a combinator
> function feels a little "inside out."