Defender methods and compatibility
Alex Buckley
alex.buckley at oracle.com
Mon Nov 29 16:12:51 PST 2010
Hi Nathan,
On 11/29/2010 3:17 PM, Nathan Bryant wrote:
> Neal,
>
> Maybe I just don't get it. In Brian and Oracle's version, changing the
> default may be source incompatible, only if the change is to which
> static method provides the default. Changing the body of that static
> method should usually be source compatible.
>
> In your preferred solution, there is no source compatibility at all, in
> the case where two superinterfaces wish to provide defenders for the
> same method. Requiring the implementing class to resolve the ambiguity
> is not source compatible.
In Neal's scheme, mod-extn is always SC because any ambiguity that could
occur in an implementation class was _already_ disambiguated when the
second extension method was _added_. (Jim Mayer is quite right in his
observation that inline defaults "push some of the risk of breaking
source compatibility back on to the act of adding an extension (add-extn).")
It's a clever trick, but throwing away the ability to compare default
methods is a huge disadvantage given that a single class may obtain
defaults from a _graph_ of superinterfaces not just a tree.
Alex
More information about the lambda-dev
mailing list