defender methods and method of Object
david.holmes at oracle.com
Mon Mar 12 17:10:16 PDT 2012
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" , 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.
> 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.
>  http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html
More information about the lambda-dev