Formal model for defender method resolution
David Holmes
David.Holmes at oracle.com
Tue Feb 1 02:11:56 PST 2011
Stephen Colebourne said the following on 02/01/11 19:58:
> On 1 February 2011 08:05, Peter Levart <peter.levart at marand.si> wrote:
>> So what we have here is two distinct desirable semantics for an interface method that overrides a method in a superinterface:
>>
>> a) re-abstraction (that discards any default definition in a supertype)
>> b) re-declaration (that inherits any default definition from a supertype)
>>
>> These two semantics can both be supported, followed by two distinct syntaxes:
>>
>> interface A {
>> Object m() default Defaults.m;
>> }
>>
>> interface B extends A {
>> Object m(); // re-abstraction
>> }
>
> While a rare case, I do think the re-abstraction case is worth
> supporting if at all possible.
>
>> interface C extends A {
>> Object m() default; // re-declaration which inherits default from A
>> }
>
> Or be more explicit - use a reference to a super-interface as the
> default. Its eminently readable and understandable:
>
> interface C extends A {
> Object m() default A.m();
> }
I'm wondering about the semantics of this. Does it mean "look up A's
default for m() at compile-time and mark my default as Defaults.m()"; or
does it mean "mark my default as the same as A.m() and at runtime go
look that up" ?
What I like about Peter's suggestion of just using "default" is that it
implies exactly the same semantics as the current proposal to always
inherit - hence we know it is implementable within the current proposal.
Though it too can have different semantics:
- find the first default implementation in my inheritance hierarchy
- use the same as my immediate ancestor
and those two are quite different. I think I prefer the latter but I can
see arguments for and against each.
David Holmes
More information about the lambda-dev
mailing list