Defender methods and compatibility

[Neal Gafter]

On Mon, Nov 29, 2010 at 4:12 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

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

I don't understand why you say this is a disadvantage.  I also don't see why
you describe it as a "trick"; I haven't suggested adding anything, only
taking away counterproductive complexity in the spec.

I suspect all this complexity is attempting to ameliorate a disadvantage of
declaration-site extension methods compared to use-site extension methods,
which is that some users will want extensions not included in the original
interfaces (e.g. java.util collections and Google collections).  They will
therefore want to develop libraries of extended interfaces with additional
extension methods not contemplated in the original set.  Clients of these
extension interfaces who inherit in a diamond pattern could well experience
the kind of ambiguity that you're attempting to support (without ambiguity).

However, in the absence of your special treatment of "extension methods with
the same default", the designer of the set of extension interfaces (of the
authors of the default methods that are widely used as extensions) could
arrange to move their new extension method higher in their interface
hierarchy, to a new interface if necessary, to achieve the same level of
binary and source compatibility for its clients without any special
treatment in the language.

-Neal