Defender methods and compatibility

[Alex Buckley]

On 11/23/2010 7:44 PM, Neal Gafter wrote:
>     I agree with the first sentence; an ambiguity results in a
>     compile-time error. As for the second sentence, the sense of an
>     extension method is precisely that its default (whether given by
>     name or by value in the interface) becomes part of the method's
>     logical "signature". How could it be otherwise, given
>     declaration-site extensions and separate compilation?
> 
> It could easily be otherwise: place the extension method bodies in the 
> interfaces and treat every method body as distinct from every other 
> method body.

I don't understand how this preserves source compatibility. Start with 
the following types that compile and run:

interface I {}
interface J {}
class C implements I,J {}

Now modify and recompile I only:

interface I { extension void m() { BODY_I } }

It turns out to be source-compatible because C would still compile. Now 
modify and recompile J only:

interface J { extension void m() { BODY_J } }

Now C would not compile. We all agree C must be changed so it declares m 
and (probably) delegates to I.m or J.m. But the add-extn to J remains a 
source-incompatible change.

Alex

P.S. add-extn and mod-extn on an interface are SC if _all_ classes that 
implement the interface define (by declaration or by class inheritance) 
the method that gained/changed extension. But there's no way to check 
it, of course.