Defender methods and reabstraction

[Maurizio Cimadamore]

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

Maurizio