Formal model for defender method resolution

[Alex Buckley]

On 1/28/2011 3:55 PM, Neal Gafter wrote:
> Die due to no f impl, exactly as it does today.  In this case it is 
> irrelevant that one of the newly added methods has a default, as that 
> default could not possibly be the one that the call resolves to.  This 
> is a situation that occurs today and that is indeed what happens.

Why bother with defenders if a call to a defended method (and I think
C.f _is_ defended by A.f, despite B.f) is going to die at runtime?

Not sure what you mean by "that default could not possibly be the one 
that the call resolves to." The caller who causes execution of 
invokeinterface B.f()B; has no idea whether the receiver class 
implements f via a defender or via declaration/class inheritance.

>     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.
> 
> Agreed!  Which is why B.f should not inherit A.f's default.
>  
> 
>     So either there should be an error on B;
> 
> 
> Huh?  Why?  This is a simple case of reabstraction.  There's nothing 
> wrong with B.  There might or might not be something wrong with some 
> further derived type, but B is fine.

It's not reabstraction if A.f is given a defender after B gains f. 
Defending the highest superinterface alone seems like a common migration 
path, one we should support.

>     or no error yet _B.f inherits
>     A.f's default and the inherited defender is typechecked in its new
>     environment_.
> 
> Huh?  Why?  When you reabstract a method, it has no implementation to 
> inherit or check.

Again, why do defenders if defending a method in a top superinterface is 
going to be undone by "accidental" overriding (by rather hopeless 
abstract methods) in subinterfaces?

Alex