Bikeshed opportunity: compose vs composeWith

[Brian Goetz]

>> At first I thought this was "same as above", but now that I think
>> about it more it is possible.  This would involve overloading:
>>
>>   thenBy(Comparator)
>>
>> with
>>
>>   thenBy(Function<T,U extends Comparable>)
>>   thenBy(IntFunction<T>)
>>
>> in Comparator.
>>
>> It also looks OK outside the sort example:
>>
>>   Comparator byFirstLast = byLast.thenBy(Person::getFirst);
>
> It's the same explosion as sortBy.
> so if you accept several overloads un Comparator, we should accept the
> several overloads of sortBy.

It's not the same explosion at all!

In the sortBy case, we had:

  functionality x output type x direction x parallelism

which for List was:

  { sort, min, max } x { object, int, long, double }
                     x { forward, reverse }
                     x { serial, parallel }

which comes out to 48 methods just for List!  And another big chunk for 
Stream.

Adopting Don's suggestion adds four new methods to Comparator in 
addition to the four compose methods we had already, plus the one method 
we had for reverse.  These together support 24 of the above 48 
combinations (still need serial and parallel), and have a similar effect 
on anything else that needs sorting support.  In this scheme, you are 
multiplying 4 by a much much smaller number.

The cure for combinatorial explosions at the leaves is combinators.