> On May 14, 2015, at 7:24 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.
An easy solution to both of these problems is to use a different name. We
discussed this as a workaround when designing the "no default 'hashCode'
method" restriction.
interface List<E> {
...
/** Returns the hash code for this list. The hash code of a list is
defined as ... */
int hashCode();
/** Computes a hash code consistent with the specification of 'hashCode'. */
default int defaultHashCode() { ... }
}
(Details like whether it's static or instance, and what interface it lives in,
are flexible.)
—Dan
