Comparators.comparing overloads

[Ali Ebrahimi]

Hi,
if we make compiler smarter and always primitives functional descriptors
wins over boxed (& Refference)
functional descriptors in that case we can disambiguate this case. With
this approach we don't need to mangle method names(just one map with
overloads).


On Mon, Jul 22, 2013 at 1:46 AM, Richard Warburton <
richard.warburton at gmail.com> wrote:

> Hi,
>
> We only mangle the name for return types, not argument types.
> >
>
> Thanks for the prompt reply.
>
> Things still seem a little messy in this situation though.  Perhaps I've
> missed something but we're talking about needing a cast for
> any keyExtractor function that returns a number.  That seems to be a fairly
> common scenario for a keyExtractor.  Suppose I want to sort Strings by
> length, and I want to write:
>
> Comparator<String> comparator = comparing(String::length);
>
> I'll get an error telling me that the "reference to comparing is
> ambiguous".  Now in fact I can't even hint to the compiler using a return
> type cast as with the following snippet:
>
> Comparator<String> comparator = comparing(str -> (int) str.length());
>
> I presume this is because a cast to int can auto-box to Integer which
> subtypes Object, so its still ambiguous between Function and ToIntFunction.
>  Again, perhaps I've missed something here, but the way to get around this
> issue is by providing an explicit type for the keyExtractor function:
>
> ToIntFunction<String> lengthOfString = String::length;
> Comparator<String> comparator = comparing(lengthOfString);
>
> Which really does seem less elegant to me than having overloads with
> mangled names. As I say this isn't a weird corner case - numbers are an
> obvious thing to use as a comparator key.
>
> regards,
>
>   Dr. Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>
>