Defender methods and reabstraction
maurizio.cimadamore at oracle.com
Thu Dec 2 02:27:00 PST 2010
On 02/12/10 10:11, Rémi Forax wrote:
> Le 02/12/2010 11:00, Maurizio Cimadamore a écrit :
>>> I don't understand your point, here.
>>> The spec already says that if X implements A and B and B extends A,
>>> only default methods from B should be considered.
>> To some extent you are right, the spec already considers case in
>> which a default overrides another. However it is not crystal clear
>> what should happen when you have A<:B, where A provides a default and
>> B does not (re-abstracted). In this case, since there's no default in
>> B, the spec seems to suggest that the default in A should be
>> considered, which is in contrast with standard overriding rules. The
>> solution is to throw re-asbtracted method into the picture and to
>> deal with them as if they were default methods where the default impl
>> is unspecified. Then the spec text follows cleanly.
> "... as if they were default methods where the default impl is
> unspecified ..."
> javac perhaps need something like that but in my opinion this too
> implementation specific for a spec.
This wording is mine, and I just used it for explanatory purpose - it's
up to Brian to come up with a crystal clear and unambiguous definition
for that! :-P
Jokes apart, the whole point is that the spec should be clear about
this, and currently is not; there a few sections in the current draft
that seem to take for granted that the only methods we need to care
about during dispatching are extension methods (i.e section 3 bullet
#2), and this is not true in the case of re-abstraction. If it is an
obvious thing, then stating it explicitly won't do any harm.
More information about the lambda-dev