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