Defender methods and compatibility

[Maurizio Cimadamore]

On 30/11/10 01:39, Howard Lovatt wrote:
> I am with Neal on this one, I think the default method should not be
> part of the method signature. In particular:
>
> 1. The case of inheriting the same method twice is rare (see note at
> end), therefore it is not a large burden to manually resolve this
> ambiguity and I favour explicit, over implicit, resolution (this is
> also a characteristic of Java in general). Be consistent with the rest
> of Java.
>
Hi
About being consistent with the rest of Java, I'd like to point out a 
kind of failure that is reminescent of what has been discussed in this 
(and related) thread; suppose we have the following class hierarchy:

class A {
void m(int i, Object o) {}
}

class B extends A { }


And a client class:


class Client {
{ new B().m(1,1); }
}


Now, suppose to add a method to B (which is a binary compatible operation):

class B extends A {
void m(Object o, int i) {}
}

The client will now start to fail, because the call-site has become 
ambiguous (resolution has now two unrelated version of m to choose 
from). To some extent, implicit resolution have been supported in Java 
for a long time (overload resolution); sometimes like in the case above, 
you might think that having implicit resolution is bad, as the outcome 
of the compilation process is kinda unexpected. However, I think that an 
implicit resolution strategy must be evaluated in terms of 'how well 
does it perform in the general case' and not on the basis on obscure 
corner cases (as the one above is).

Maurizio