Defender methods and compatibility

[Reinier Zwitserloot]

When is the currently proposed "default method is part of the signature"
aspect going to result in a problem? If this is about ideological purity,
then I vote we stop painting this bikeshed.

 --Reinier Zwitserloot



On Mon, Nov 29, 2010 at 4:00 PM, Neal Gafter <neal at gafter.com> wrote:

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