Defender methods and compatibility

[Robert Field]

  On 11/29/10 15:06, Rémi Forax wrote:
> 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.

I believe this is what is being referred to is a case like this:

     interface A {
         public extension int get() default Implementations.one;
     }

     interface B {
         public extension int get() default Implementations.one;
     }

     class X implements A, B { }

And, Neal, if I understand your point, having this conflict 
automatically resolve is dangerous, if, for example, A is changed to:

     interface A {
         public extension int get() default Implementations.somethingElse;
     }

-Robert

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