defender methods and method of Object

[Jack Moxley]

I think he has a point, perhaps object is special as it is conceptually both interface and implementation. We have merely hit a design flaw.

Object as the root of all inheritance is a special case all over the shop I am not quite sure why people are so hesitant at allowing it to be different yet again.

Sent from my iPhone

On 13 Mar 2012, at 02:57, Neal Gafter <neal at gafter.com> wrote:

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