Defender methods and compatibility

[Rémi Forax]

On 11/30/2010 12:40 AM, Robert Field wrote:
>    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

But here the default method of A::get is Implementations.one(A) and
the default method of B::get is Implementations.one(B).
It's not the same method.

Rémi