Defender methods and compatibility

[Alex Buckley]

On 11/23/2010 4:11 PM, Neal Gafter wrote:
> On Tue, Nov 23, 2010 at 11:31 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
> 
>> While this restriction may be unsatisfying, this is really not all that
>> different from the existing SC* behavior of add-meth.
> 
> Indeed this (binary incompatibility with mod-extn) is particularly
> unsatisfying because the binary compatibility rules are designed
> specifically to be insensitive to changes of implementation details.

You're misreading the asterisks. mod-extn is binary compatible always.

> Fortunately, you can do much better by removing the special rule about
> allowing inheriting multiple extension methods with the same default
> (without ambiguity).  Without this rule, programmers will explicitly resolve
> the ambiguity at the point where multiple extensions with the same signature
> are inherited.  In that case changing an extension method's default is both
> source and binary compatible.

It's impossible to guarantee source compatibility when changing an 
extension method's default, unless you force a class whose 
superinterfaces have _any_ extension methods to choose a preferred 
extension method even when there's no ambiguity. But the whole point is 
to avoid changing implementation classes except where absolutely necessary.

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. We already support that change (see section 6 
of the V3 defender methods doc) and moreover it's only necessary at 
compile-time when a real ambiguity has been introduced.

Alex