Comparator

[Zhong Yu]

What I meant was,

    void foo(X->int){ ... }

    foo(x-> new Integer(0));  // should not compile

programmer should need to explicitly unbox

    foo(x-> new Integer(0).intValue());

I imagine this is a rare use case, so we better not add a new
dimension of complexity to inference just to make it easier.

Zhong Yu



On Mon, Jul 15, 2013 at 11:25 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 15/07/13 17:15, Zhong Yu wrote:
>>
>> Auto unboxing is evil all around. I config my IDE to mark it as error.
>
> Problem is, if you can't look at the lambda, how do you tell if there's
> boxing? You only know that two methods are applicable, one that requires a
> lambda that returns an int, another requiring a lambda that returns a
> reference - it would be premature to pick the first over the second, as you
> still don't know what the lambda does.
>
> Maurizio
>
>>
>> Do we really need auto unboxing in type inference? It seems like a fringe
>> case.
>>
>> On Mon, Jul 15, 2013 at 11:09 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>> On 15/07/13 16:53, Marc Petit-Huguenin wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> Hi,
>>>>
>>>> I am trying to use a comparator on a Map.Entry<String, Integer> stream,
>>>> and I
>>>> am not sure why this does not compile:
>>>>
>>>> .sorted(Comparator.comparing(Map.Entry::getValue))
>>>
>>> This is as expected - the method reference Map.Entry is defined on a
>>> generic class with unknown parameter types (some Map<K, V>) - therefore
>>> the compiler needs the info from the target (in a top-down way) in order
>>> to decide what the method reference looks like. But the target type info
>>> is incomplete as it depends on inference variables on its own.
>>>
>>> So the compiler ends up applying a simpler (arity-based only) check
>>> during overload resolution - which means the compiler can't really pick
>>> the right comparing() method ahead of the target-type.
>>>
>>> A shorter way to get this to compile should be this:
>>>
>>> .sorted(Comparator.comparing(Map.Entry<String, Integer>::getValue))
>>>
>>>
>>> Let me know if that works for you.
>>>
>>> Maurizio
>>>>
>>>> error: reference to comparing is ambiguous
>>>> error: incompatible types: Cannot instantiate inference variables T
>>>> because of
>>>> an inference loop
>>>>
>>>> (interestingly the second error was not present when using a build from
>>>> last week)
>>>>
>>>> These two compile:
>>>>
>>>> .sorted(Comparator.comparing((ToIntFunction<Map.Entry<String,
>>>> Integer>>)Map.Entry::getValue))
>>>>
>>>> .sorted(Comparator.comparing((Map.Entry<String, Integer> entry) ->
>>>> entry.getValue().intValue()))
>>>>
>>>> Thanks.
>>>>
>>>> - --
>>>> Marc Petit-Huguenin
>>>> Email: marc at petit-huguenin.org
>>>> Blog: http://blog.marc.petit-huguenin.org
>>>> Profile: http://www.linkedin.com/in/petithug
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.12 (GNU/Linux)
>>>>
>>>> iQIcBAEBCAAGBQJR5BrvAAoJECnERZXWan7Em7UP/1YH+kupYW2bcANs+BrfgbdW
>>>> npniz63F1GDjWC9IqAd0FREGXEcoAqQCYN3r292APQ4kirSxP4imV8LC9Gof86B/
>>>> VGNoxMLpxIxAELWA6Ps1EANFypFf19Rot1fCAAcKBqon4gGBf/IC+BhOkydtnm74
>>>> FVOytk8jkjSWz8DikZ7Z48xBVcR6wMQrPAjh/II0zMt+gqXZY1nLeFFEoaQJDyHs
>>>> u4wxySolO7BrF63s/mxz89PuxLA5vuEMVdehTOgcvz3QZu2KZJ+gk7Y96PZOMdoU
>>>> eMGfpIPxNlab5pRJXPoHn7XiiWPo+VKHs7SkInhqU49HL/uFNZjdn+rH1gbN4M7H
>>>> sn6rMt1b9+BNVad8mlMwby5REE1+qoC9ActisEQlHKlwc+W1Suz+oKjfBWhzjQmv
>>>> tHvhaTscSFwY0SewR1D3YaCBAcGllUU0078yWqTCRHeTVmuCjfqDAMTPn515tVsr
>>>> Rds4uIdESoBY3kDc3OazZEKO9TD7OdsSuhAMeIv7aooNQqtQ1JlC93D8od8lXfC1
>>>> 25/Tyt6WXT1pp1TMURvzIw2YNgLXrTWi1wjQaQm5yqeBgfcKdPGbjzyYbAaQlA1i
>>>> PiGPfyIyg/GtTGeyO4M8mgbAo/p0w2PQU0iK+oQDWDEoKDt1wQNZMLf6VzQSpKqm
>>>> /1syZfGWNEl3J7fuvh/o
>>>> =h+Kp
>>>> -----END PGP SIGNATURE-----
>>>>
>>>
>