defender methods and method of Object

[Neal Gafter]

This would introduce a cycle into the inheritance graph Object ->
ObjectDefaults
-> Object.  Not such a good idea.

On Mon, Mar 12, 2012 at 5:40 PM, Henri Gerrits <henrigerrits at yahoo.com>wrote:

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