Defender methods and compatibility

[Neal Gafter]

On Tue, Nov 23, 2010 at 5:13 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> On 11/23/2010 4:55 PM, Neal Gafter wrote: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.
>

I don't believe that is true.


> 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?


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.