Defender methods and compatibility
Howard Lovatt
howard.lovatt at gmail.com
Mon Nov 29 17:39:42 PST 2010
I am with Neal on this one, I think the default method should not be
part of the method signature. In particular:
1. The case of inheriting the same method twice is rare (see note at
end), therefore it is not a large burden to manually resolve this
ambiguity and I favour explicit, over implicit, resolution (this is
also a characteristic of Java in general). Be consistent with the rest
of Java.
2. If the default method becomes part of the signature then it will
make including method bodies in interfaces difficult in the future.
This is saying that we might want to include method bodies in the
future, don't close the door. Be cautious about language change.
3. It will encourage bad practice. Instead of defining a common base
interface people will be tempted to just keep adding extension
methods. IE it is along the lines of structural typing, whereas Java
is primarily nominally typed. Encourage best practice (even though I
accept that it is likely to be a rare abuse).
4. Some people think of the default method as part of the
implementation detail, others as part of the method signature. To me
it is more an implementation detail or more like an annotation. This
is clearly a grey area, but my call is 'implementation detail'.
-- Howard.
Note:
The reason I think that inheriting the same method twice is rare is
that most cases of multiply inheriting the same method I have seen are
variations on the diamond problem, e.g.:
interface N { extension void m() default Ns.m; }
interface W extends N {}
interface E extends N {}
class S implements W, E {}
and under either set of rules this isn't a problem. The use case that
the two rules differ on is:
interface W { extension void m() default Ns.m; }
interface E { extension void m() default Ns.m; }
class S implements W, E {}
in the proposed rules this isn't an error but with Neal's rules you need to say:
class S implements W, E { public void m() { W.m(); } } // or similar
I have seen this later case (in languages that allow multiple
inheritance) of defining the same method twice, but I have seen the
diamond problem considerable more often and hence think the problem
will be rare in practice.
More information about the lambda-dev
mailing list