Defender methods and compatibility

[Neal Gafter]

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.

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.*