Defender methods and compatibility

[Rémi Forax]

On 11/29/2010 11:28 PM, Neal Gafter wrote:
> On Mon, Nov 29, 2010 at 9:53 AM, Reinier Zwitserloot<
> reinier at zwitserloot.com>  wrote:
>
>> 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.
>>
> An interesting reference to Parkinson's *law of triviality*.  The basis of
> Parkinson's law is that people seem to care less about issues they don't
> understand, no matter how important those issues might be relative to the
> issues for which they express a preference.  "painting this bikeshed" is an
> *ad hominem *suggestion that the participants in this discussion are really
> only commenting on those issues simple enough for them to understand.
>
> In this case, however, you also appear to be saying that you don't fully
> appreciate the issue, and therefore don't see any point in continuing the
> discussion.  Which ironically reinforces the reference to Parkinson's law.
>
> To be (hopefully) more clear, here are the costs of the current approach:
> o New syntax for extension methods (as opposed to using the existing method
> body syntax)
> o Changing the default of an extension method is not source compatible (in
> the sense that it can cause some existing clients to no longer compile)
> o Under the current draft spec, not binary compatible either, but there have
> been promised (as yet unexplained) complexities to be added to method
> resolution (and therefore the JVM) that may be introduced to reduce this
> effect.
>
> Here are the benefits:
> o Certain compile-time ambiguities might be avoided when extension methods
> in unrelated classes have the same signature and implementation.

How unrelated classes can have the same default method ?
The spec says that the first parameter of a default method
is the class containing the extension method.

> The practical impact of the source incompatibility is that an API designer
> cannot change an extension method's default without potentially breaking
> some clients (i.e. causing them to no longer compile).  That is so because
> the API designer generally does not possess all of the client code of the
> API to test against to ensure they all still compile.  Changing the default
> implementation is just the sort of change an API designer would want to make
> from one release to another to, for example, improve performance.  But the
> fact that it is an incompatible change inhibits the API designer from making
> such changes in the future.  As a consequence, the language feature as
> proposed is more likely to result in future APIs that have more (rather than
> fewer) artifacts of their history.  Historical artifacts are one of the pain
> points of the Java platform that we'd be better off minimizing.
>
> The default of an extension method is not a part of the programmer-visible
> API in any useful, observable sense *except to the extent that it can
> introduce this incompatibility.*

Rémi