Formal model for defender method resolution

[Neal Gafter]

On Fri, Jan 28, 2011 at 5:06 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

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

Because C.f has no implementation, inherited or otherwise, for the abstract
method B.f.  C.f is not defended.


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


Either way, there is no concrete method anywhere in that program with that
signature (or a subsignature).  So it must fail at runtime.


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


That would be fine if it were sound.  It isn't.  By analogy, in a class
hierarchy an abstract method declared in a derived class isn't implemented
by a newly added concrete method in its superclass; I don't see why
interfaces should be any different.


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

I don't see how the language is supposed to know which overrides are
accidental and which are intentional.  It is reasonable for the
language/compiler to assume that they are all intentional.