Defender methods and compatibility

[Brian Goetz]

> It is clear that's not how it works, and that's the problem with the current
> specification.  The default shouldn't have any concept of "identity" separate
> than that of the method itself, nor should the specification add a new way for
> compatibility to be broken.

You keep using the word "should" as if there is a a categorical principle 
here, but I don't see it.  I have proposed a design for a language feature. 
You would prefer a similar but slightly different feature.  Not surprising, 
there's more than one way to skin a cat.

(Further, I think you're making a lot of noise about a corner case. 
Collisions are likely to be rare.  In the vast majority of cases, API 
designers will be able to make changes to defaults without breakage.)

I welcome your opinion but you will need to do a lot better than just chanting 
"should, wrong, broken" if you want to influence the outcome.

>     The exact same sort of caveat is in operation for mod-extn.  mod-extn is
>     source-comptable, except when it causes a conflict with a subclass that
>     inherits the method *and* the same method with a different default from
>     another (unknown to the modified interface) interface.  While this sort of
>     conflict may well be more likely than the sort in the previous example (or
>     may not, we're not sure yet), it is definitely of the same flavor.
>
> It isn't the exact same sort of caveat: here the proposal adds a new kind of
> incompatibility previously absent from the language.  Changing a method's
> implementation (e.g. its default implementation)

Objection, assumes facts not in evidence.  You keep assuming that the identity 
of the default is an implementation detail, and then state that as fact.  You 
are incorrect, it is not an implementation detail.  The *body* of the method 
is, as method bodies always have been, an implementation detail.  But the best 
way to think about the default is that it is part of the signature.