defender methods and method of Object

[David Holmes]

Dan,

On 13/03/2012 5:31 AM, Dan Smith wrote:
> 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 don't follow your reasoning here. The "methods that are already 
overridden by other candidates are ignored" rule only apply to 
interfaces and only comes in to play when the first rule (class methods 
beat defaults) does not apply.

I don't think special-casing Object methods is warranted. I'm also 
unclear what the impact would be on runtime method lookup - or would it 
just affect how the vtable gets constructed at class loading time?

I'm concerned that default methods are being seen as a new way to 
construct type hierarchies, rather than just being a short-term way to 
add a new method to an existing interface. In my opinion developers who 
subclass interfaces to which default methods get added, should implement 
those new methods in the next version of their libraries/apps - so that 
they don't rely on implicit use of defaults (they can make it explicit 
if it suits their needs). Default methods provide an evolution path for 
interfaces, but they can very easily be mis-used.

David
-----

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