Defender methods and compatibility

[Alex Buckley]

On 11/24/2010 2:38 PM, Neal Gafter wrote:
>     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.
> 
> Right.  We agree that add-extn is a source-incompatible change.  My 
> point was that mod-extn should be a source-compatible change, but you've 
> specified it to be a source-incompatible change.

There has been some confusion - you started by quoting Brian's comment 
on add-meth, which should be compared to add-extn, but you raised a 
point about mod-extn and its relationship to mod-meth.

The initial summary mail should have compared add-extn specifically to 
add-meth, and mod-extn specifically to mod-meth.

When I wrote earlier about "changing an extension method's default", I 
was mainly thinking of adding a default, which we all agree is not 
guaranteed SC. Specifically, I was thinking of changing an interface 
method into an extension method by adding a default. That's one case of 
add-extn. (The other is adding an extension method signature from scratch.)

Anyway, the good news is that mod-extn _is_ SC. That's true whether a 
default is specified in the interface via a method body or a method name.

If specified via a method name, then independent mod-extn actions (or 
add-extn - there it is again!) on different interfaces _may_ still be SC 
for an implementation class. Some people see this as an optimization we 
can leave out; that may be so, but it is not a prima facie reason for 
preferring method bodies.

Alex