Comparator/Comparators API change proposal

Remi Forax forax at univ-mlv.fr
Tue Jun 4 16:25:15 PDT 2013


On 06/05/2013 12:32 AM, Remi Forax wrote:
> On 06/04/2013 11:36 PM, John Rose wrote:
>> On Jun 3, 2013, at 2:33 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>
>>> 2. Rename various comparing methods to comparing, comparingInt,
>>> comparingLong and comparingDouble accordingly.
>> This seems like a code smell.  Let me see if I understand the issue:
>>
>> When users sort with primitive-valued key extractors, they will have to add noise words "Int", etc., to their code to get the compiler to accept the code.
>>
>> These noise words exist only to get past a technical overloading difficulty, and do not capture logical details of interest to the user.
>>
>> Moreover, if users leave out the noise words, the code will still compile and work almost* the same (due to autoboxing).
>>
>> (*Because java.lang.Double comparison is a little different from double comparison.)
>>
>> E.g., comparing(String::length) == comparing( (Function<String,Integer>) String::length ) == comparing( (String s)->s.length() ).
>>
>> This extra help to the compiler is needed because it doesn't know IntFunction<T> is preferable to Function<T,Integer>, when resolving overloadings.
>>
>> That is because IntFunction<T> does not extend Function<T,Integer>.
>>
>> Is that right?
> or because in the inference mechanism, Integer is not recognized as the
> boxing of an int,
> or if you prefer T -> int is not a specialization of T -> Integer.

To be a little more specific.
The way the JLS specifies how to find the set of applicable methods 
works in 3 phase, it first only consider the type without boxing or 
varargs, then boxing and then boxing and varargs. This algorithm has two 
purposes. One is that it was backward compatible with the way the set of 
applicable methods was calculated before java 5 but in that case only 
two phases (instead of 3) are enough. The other purpose is that it 
provides specialization, if there is two possible candidates, one that 
does boxing and the other that doesn't boxing, the one that does no 
boxing will be chosen. I believe the same strategy should be used when 
comparing function type.

>
>> — John
>>

Rémi



More information about the lambda-dev mailing list