Map.Entry.setValue as a default method
Remi Forax
forax at univ-mlv.fr
Thu Nov 21 06:56:20 PST 2013
On 11/21/2013 02:08 AM, John Rose wrote:
> On Nov 20, 2013, at 4:31 PM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> 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
More information about the lambda-libs-spec-observers
mailing list