AbstractList etc. functionality as interfaces with default methods?

[Vitaly Davidovich]

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
>
>