Formal model for defender method resolution

[David Holmes]

Peter Levart said the following on 02/02/11 18:57:
> On 02/02/11, David Holmes wrote:
>> I have to disagree with you there. The semantics for A.m, B.m and C.m 
>> are potentially different, so what semantics does D.m provide ? 
> 
> I would say (considering my suggested semantics of "default none")
> that C.m does not provide any semantics (it just forces the implementor
> or a mixer to provide one). So "D" here is "a mixer" that mixes in A.m
> and B.m defaults, which are, unfortunately, conflicting.

My starting premise for these discussions is that you override an 
interface method like m() to modify its semantics. So C.m requires 
different semantics to A.m and B.m, and so "default none" is saying "I 
don't have a default" because the existing defenders are not known to 
have the right semantics.

David

> 
> Is anything wrong with this reasoning?
> 
> Regards, Peter
> 
>> We have 
>> no idea looking at what has been written. Of course this can happen 
>> today without defenders, but we assume that an implementor of D can 
>> somehow make sense of this strange situation. But with defenders in play 
>> it doesn't make sense to me for this situation to be ignored by the 
>> compiler because the compiler can see there are two conflicting 
>> defenders at play here: X.b from B and <none> from C. From D's 
>> perspective B and C have equal weighting, so it is ambiguous what 
>> defender D.m should have. Hence the programmer should be forced to 
>> explicitly resolve that ambiguity in my view. Why do you consider B's 
>> defender to be more relevant to D than C's?
>>
>>> The same situation can occur with classes today:
>>>
>>> *class A<T> {
>>>   public T m() { ... }
>>>   public abstract String m();
>>> }
>>> class D extends A<String> {
>>> }
>>> *
>>>
>>> In this case the inherited non-abstract m implements the inherited abstract
>>> m.  It seems that we should allow the same thing for interfaces: a
>>> (non-overridden) inherited concrete method should be capable of implementing
>>> an inherited abstract method.
>> Is this is an example we should strive to emulate? It seems an extreme 
>> quirk of generics. Is there a realistic use-case for this?
>>
>> David Holmes
>>
>>