Defender methods and compatibility

[Neal Gafter]

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

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


Not with the currently published specification.  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.

 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.


I hear what you're saying but I don't understand why you believe it.
Perhaps your concept of "even when there's no ambiguity" includes reference
to details of the implementation of extension methods (i.e. what code is
executed), which is exactly the kind of error I'm proposing you fix.  If you
mean something else, perhaps you can convince me by demonstrating it.


> But the whole point is to avoid changing implementation classes except
> where absolutely necessary.
>

If the specification for extension methods did not make its ambiguity rules
refer to the implementation of the extension methods (and I suggest that it
should not), then there is no way that changing the default could introduce
a source incompatibility.

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.