Defender methods and compatibility

[Alex Buckley]

On 11/23/2010 4:55 PM, Neal Gafter wrote:
> On Tue, Nov 23, 2010 at 4:33 PM, Alex Buckley <alex.buckley at oracle.com 
>     You're misreading the asterisks. mod-extn is binary compatible always.
> 
> Not with the currently published specification.  

Right; Brian's mail stated there are details yet to be published.

> In any case, my comment holds true for source compatibility as well:
> the language is currently designed so that the change of an
> implementation detail in one place does not break source
> compatibility elsewhere.  The current proposal undermines that design
> goal.

As does any proposal to have method bodies directly in interfaces.

Let's cut to the heart of the issue:

>     In other words: start with a class whose superinterfaces have no
>     ambiguity about multiple extension methods; now recompile one of
>     those superinterfaces so there's an ambiguity; the class cannot now
>     be recompiled without change.
> 
> Indeed, it should not be possible to "recompile" to introduce an 
> ambiguity.  Only changes to the public API should be capable of 
> affecting binary or source compatibility.

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?

Alex