On 11/21/2013 02:08 AM, John Rose wrote:
On Nov 20, 2013, at 4:31 PM, Remi Forax <[email protected]
<mailto:[email protected]>> wrote:
But while you can declare a default hashCode and equals, it will not
work because the implementation of Object.hashCode and Object.equals
will always be preferred to the default methods by the VM, this is
how default methods are specified. Not something I'm very proud.
Next question: What's the best practice for declaring reusable code
for exactly those restricted methods (hashCode/equals, toString)?
Because of the irregularity with Object, the opt-in isn't by default,
but there should still be a convention for supplying the code as a
"would-be default method".
Maybe one of:
interface KoolReusablePair {
default boolean defaultEquals(Object x) { ... }
static int hashCode(KoolReusablePair self) { ... }
...
}
class KoolImpl implements KoolReusablePair {
@Override //manual opt-in:
public boolean equals(Object x) { return
KoolReusablePair.super.defaultEquals(x); }
@Override //manual opt-in:
public int hashCode() { return KoolReusablePair.hashCode(this); }
...
}
— John
The plumber in me think that a static method unlike a default method
will not pollute the itable.
regards,
Rémi
