The static-instance asymmetry cancels that one out. If you have
class Foo {
void m(int x)
static void m(Foo f, int x)
}
Then Foo::x could either be an unbound mref to the instance method or a static
mref. Even with a perfect target type (Foo, int) -> void, compiler will still
report ambiguity.
On May 14, 2015, at 9:52 AM, Vitaly Davidovich <vita...@gmail.com> wrote:
> Ambiguous in isolation, but within context they're quite different: one
> takes an arg and the other is void.
>
> sent from my phone
> On May 14, 2015 9:25 AM, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>
>>
>>
>> On 05/14/2015 03:05 PM, Brian Goetz wrote:
>>
>>> Not only is there a problem with modCount, but also with
>>>>> equals/hashCode/toString. You can’t define these Object methods in an
>>>>> interface.
>>>>>
>>>> They could be defined as static methods to delegate to. From API
>>>> consistency perspective, we have for example the following static methods
>>>> on primitive wrapper classes:
>>>>
>>> Right. We considered this during Lambda, but by the time we got here, we
>>> concluded that this was mostly trading one downside for another. It seemed
>>> overwhelmingly likely that people would forget to override
>>> equals/hashCode/toString in this case, and create collections that violated
>>> the contract.
>>>
>>>
>> The other problem is that it creates ambiguous method references,
>> if you have a class or an interface like:
>> class A {
>> public static int hashCode(A a) { ... }
>> }
>>
>> A::hashCode is ambiguous.
>>
>> cheers,
>> Rémi
>>
>>
