Formal model for defender method resolution

[Stephen Colebourne]

On 1 February 2011 10:11, David Holmes <David.Holmes at oracle.com> wrote:
>>> 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" ?

The latter. All defaults are in general is pointers to the real
implementation. This case is simply a pointer to a pointer (late
binding).

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

The default on its own looks a little lonely, and less explicit as to
its meaning. No one will misunderstand, or need to look up, a default
that points to an interface method.

Moreover, this allows a new form of improvement of interfaces (which I
don't think the proposal allows today, and could be very useful):

public interface Foo {
  int getEstimatedValue();
  int getValue() default getEstimatedValue();
}

Finally, if interface C extends from A and B, interface default
pointers allows conflicting defaults to be resolved in a more logical
way.

Stephen