Defender methods and compatibility

[Neal Gafter]

On Sunday, November 28, 2010, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.
> 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.

Perhaps it would help me to understand the current design if you
explain the software engineering principles and processes it is
intended to support, as the current design seems to me to undermine
the more important principle of flexibility in API evolution in favor
of the (it seems to me) less important property of automatically
resolving ambiguities in some situations when methods that are
unrelated in the inheritance hierarchy have colliding signatures.  Am
I to understand that you value these factors differently?