Sorting and comparator

[Brian Goetz]

> 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.  

> 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.