Formal model for defender method resolution
neal at gafter.com
Fri Jan 28 17:48:09 PST 2011
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
>> 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.
More information about the lambda-dev