Sorting and comparator

[Remi Forax]

On 11/21/2012 12:43 AM, Brian Goetz wrote:
>> This idiom as two problems in my opinion,
>> first you have to call the static method comparing which make the code ugly
>> and hard to produce with an IDE if the only keys you know on your keyboard
>> is 'dot' and 'CTRL SPACE'.
>> Moreover, while Person::getName is a constant lambda, the result
>> of Comparator.comparing is not a constant lambda, so the code has
>> to allocate a new lambda (in the code of Comparator.comparing at each call).
> Not in Java 8, that's true.  JohnR and I have been talking about how this can change in the future, though, with suitable annotation of the comparing() method.  Just not yet.

or the VM should be able to see through invokedynamic.

>
>> I think it's better to have two methods, sorted and sortedBy with sortedBy
>> taking a new functional interface Ordered (put a better name here)
>> defined like this:
> We started with this approach, actually, for all the same reasons you cite -- the need for the intermediate comparator combinator will surprise people.  Here's what we discovered: that there was an explosion of sortedBy methods:
>
>    sortedBy(T -> Comparable)
>    sortedBy(T -> int)
>    sortedBy(T -> long)
>    sortedBy(T -> double)
>    parallelSortedBy( ... same 4 ... )
>
> and if you wanted to support descending sort you needed
>
>    reverseSortedBy( ... 4 versions ...)
>    reverseParallelSortedBy(... 4 versions ...)
>
> (16 so far) and if you wanted to support composition of sort keys you need 4x more for each layer of composition (since you might want compose(T -> int, T -> Coparable), etc.
>
> Plus, we'd need a similar explosion for min() and max().  And it's not just List, its anything that needs a sort method.  It was only after we saw this that we retreated towards the Comparator combinator approach, where we have one combinator for each kind of T -> something, one for reversing, and one for composing.  This dramatically reduced the API surface area.

yes,
the explosion comes from two factors, one is primitive specialization, 
the other is sort with specific comparators.
For specific comparators, overloads of Comparators.comparing are fine
(even if Comparator.comparing is better, but let this aside for now).

Now, I think that sortedBy is too common to not provide a specific 
method in Stream.
Given that all overloads of sortedBy, sortedBy(T -> Comparable), 
sortedBy(T -> int), sortedBy(T -> long) can be written as
default methods calling sorted(), adding sortedBy will increase the 
number of method of Stream but not the conceptual weight.

BTW, this highlight the fact that we need a way to have two views of an 
interface in the javadoc,
the user view and the implementer view.

Rémi