defender methods and method of Object

[Henri Gerrits]

Maybe Object's implementations of equals(), hashCode() and toString() can be moved to a new interface java.lang.ObjectDefaults (ugh!) as (native?) default methods.
Object can then implement that interface without providing implementations.  And then no special case is needed for Object methods when applying the conflict resolution rules of section 12, and everyone's happy.

Not sure if this is possible, though.

Henri




>________________________________
> From: Dan Smith <daniel.smith at oracle.com>
>To: Neal Gafter <neal at gafter.com> 
>Cc: David Holmes <david.holmes at oracle.com>; "lambda-dev at openjdk.java.net" <lambda-dev at openjdk.java.net> 
>Sent: Monday, March 12, 2012 3:31 PM
>Subject: Re: defender methods and method of Object
> 
>On Mar 10, 2012, at 1:01 PM, Neal Gafter wrote:
>
>> On Sat, Mar 10, 2012 at 5:06 AM, David Holmes <david.holmes at oracle.com> wrote:
>> On 10/03/2012 3:56 AM, Dan Smith wrote:
>> > Yes, I've been thinking the same thing.  Since the Object methods are morally members of every interface, it would make sense that a default method could effectively override them, and the "throw out all super methods that have already been overridden" rule could then apply.  It all depends on what order the inheritance conflict-resolution rules are applied in.
>> 
>> If you go down this path then you are throwing away the "superclass
>> implementation always wins" rule - in which case what rule are you going
>> to replace that with?
>> 
>> I suspect the rule that Dan is imagining is something like "superclass implementation always wins (except for Object implementation); if none then interface implementation wins; if none then Object implementation wins."
>
>Even simpler, actually.  See "State of the Lambda" [1], section 12, the rules described after "Two basic principles drive these rules..."  What is interesting and unique about the Object methods is that _both_ rules apply, and give different answers.  So one of the two, either "class beats interface" or "overrider beats overridden", has to take priority.
>
>I'm not wholeheartedly endorsing the idea of the "overrider beats overridden" rule having a higher priority, though.  It's plausible, and I like how it fits pretty cleanly into the model, but the model that prefers the "class beats interface" rule is also pretty clean.  The implications of either approach deserve a lot more thought.
>
>—Dan
>
>[1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html
>
>
>
>
>