Formal model for defender method resolution

[Alex Buckley]

On 1/28/2011 12:30 PM, Neal Gafter wrote:
> Your proposal here (B.m inherits A's default) feels ok to me, but I could
> see it going the other way.  Here's why.
> 
> In the more general case with covariant overriding
> 
> interface A {
>     A f() { ... }
> }
> interface B extends A {
>     B f();
> }
> 
> I don't think there needs to be any error on B.  At compile-time, any class
> that implements B will have to provide an implementation for B.f() [it is
> after all abstract], so the error on B serves little purpose.

But A and B could have gained f after the class that implements B was 
compiled. In which case, we must ensure that C responds to 
invokeinterface A.f()A or invokeinterface B.f()B with an instance of B 
or deeper.

If there's no error for the B above, and yet B.f _does not_ inherit 
A.f's default (as you suggest), then invokeinterface B.f()B; on a C will 
resolve then ... what? Die due to no f impl? Or execute A's f impl, 
possibly leading to unsoundness?

If there's no error for B, and B.f _does_ inherit A.f's default, then 
invokeinterface B.f()B on a C may return an A that's not a B, and we 
definitely have unsoundness.

So either there should be an error on B; or no error yet _B.f inherits 
A.f's default and the inherited defender is typechecked in its new 
environment_. (Dan suggests B in this scenario should not be allowed to 
silently inherit, and must provide a type-correct default body for f.)

Alex