Latest draft of Defender Methods

[Brian Goetz]

> A second somewhat obscure note: The syntax for the default method does
> not include a parameter list. Instead, presumably, if the class+method
> name is not unique (i.e. its been overloaded), then the right method is
> deduced from the parameter list of the extension method.

That is correct; the intention is that the correct method is deduced. 
However, this draft loosens the matching algorithm, which was previously just 
"receiver type prepended onto extension method argument list", to allow 
resolution using the method resolution algorithm.  We could use the same 
scheme as we use for disambiguating method references (but only when needed), 
or we could require you to write a new method that resolves unambiguously.  TBD.

> However, para 8.2 defines the relation between an extension method's
> signature and the implementation of it in terms of what the extension
> signature should look like given the implementation.

No.  The extension signature is given explicitly in the class file.  The 
default signature is the one that has to be resolved.  There's no circularity 
here.

> That's just a spec technicality, but there's also a legitimate technical
> issue here: What if the method is overloaded, and more than one
> overloaded method would 'fit', i.e. I have:
>
> extension int foo(Integer n) default X.bar;
>
> as well as, in public class X:
>
> public static int foo(Number n) { return 0; }
> public static int foo(Integer n) { return 1; }

Method resolution usually has an answer.  We piggyback on that.

> And, if this syntax is allowed, should a param-type-less default
> reference simply fail at compile time if the reference is ambiguous,
> instead of attempting the usual complicated method resolution algorithm?

Paramless can always mean "try and figure it out for me", since default 
methods can never be nilary (they always require at least a receiver.)

> Some sort of 'ambiguous' error must always be an option. For example, if
> the interface's extension method signature reads (Integer, Integer), and
> there are 2 valid methods, one with signature (Integer, Number) and the
> other with (Number, Integer).

The compiler is allowed to emit a compilation error if it cannot resolve the 
reference.