Formal model for defender method resolution
alex.buckley at oracle.com
Fri Jan 28 17:06:42 PST 2011
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
> 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?
More information about the lambda-dev