Sorting and comparator

[Brian Goetz]

+1 on the javadoc thing.  Jon and Bhavesh have been working on exactly that. 

Sent from my iPhone

On Nov 21, 2012, at 1:23 PM, Remi Forax <forax at univ-mlv.fr> wrote:

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