Defender methods and compatibility

[Peter Levart]

On 11/30/10, Neal Gafter wrote:
> 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).

I'm particularly concerned about this scenario. Lat's say vendor A (Oracle) defines unrelated interfaces A1 and A2 with a shared extension method because it assumes they might be used in a diamond pattern in implementing classes. Vendor B (Google) sees this practice and defines unrelated interface B1 with the same extension method pointing to same default because it assumes their interface might be used combined with interfaces A1 and/or A2 in implementing classes.

Now vendor A has locked itself out of changing the "signature" of extension method in interfaces A1 and A2 since changing it would brake SC (and BC) in those classes that implement A1/A2 and B1.

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

So the preferred way of defining a common extension method which could be re-used by other vendors is to define a common super-interface with a single extension method which all concerned interfaces would extend. No SC breakage would result if this "single" definition is ever changed (being inline or not).

Peter