AbstractList etc. functionality as interfaces with default methods?

[Brian Goetz]

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 <vitalyd at 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" <forax at 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
>> 
>>