SAM conversion and overload resolution

[Peter Levart]

On a second thought, yes it all boils down to API design. So if one intentionaly wanted to design an API with overloaded methods so that the "most specific" of all candidates was choosen, he/she would just have to make sure that SAM typed method parameters would be related with "real" subtype relationships - which is doable.

Regards, Peter

On 08/03/10, Neal Gafter wrote:
> I think the compiler is doing you a service by rejecting the first example.
> Overloading like this is questionable to begin with.  If the two
> overloadings have the "same" behavior on the same lambda, then it doesn't
> matter which is selected, and if they have different behavior, you probably
> don't want the compiler selecting from among the choices on your behalf.
> 
> In short, don't complain to your language designer.  Instead complain to
> your API designer.
> 
> On Mon, Aug 2, 2010 at 4:03 AM, Peter Levart <peter.levart at marand.si> wrote:
> 
> > Although the exact algorithm is currently only specified in the javac
> > sources of lambda prototype, it does quite a good job when experimenting
> > with simple usecases. I was thinking that a refinement might even be
> > better...
> >
> > The following program does not compile:
> >
> >
> > public class Closures
> > {
> >  public interface ComparableF { Comparable invoke(); }
> >  public interface StringF { String invoke(); }
> >
> >  public static void say(StringF stringFunc) {
> >    System.out.println("stringFunc says: " + stringFunc.invoke());
> >  }
> >
> >  public static void say(ComparableF comparableFunc) {
> >    System.out.println("comparableFunc says: " + comparableFunc.invoke());
> >  }
> >
> >  public static void main(String[] args)
> >  {
> >    say(#{ "Hello" });
> >  }
> > }
> >
> >
> > ... javac complains that:
> >
> > Closures.java:19: reference to say is ambiguous, both method say(StringF)
> > in Closures and method say(ComparableF) in Closures match
> >    say(#{ "Hello" });
> >    ^
> > 1 error
> >
> >
> > With a simple change to the source from:
> >
> >  public interface StringF { String invoke(); }
> >
> > to:
> >
> >  public interface StringF extends ComparableF { String invoke(); }
> >
> >
> > ... the program compiles and prints:
> >
> > stringFunc says: Hello
> >
> >
> > ... because the standard overload resolution can choose the most specific
> > method.
> >
> >
> > Now if we defined some kind of "soft-subtype" relationship among SAM types
> > that worked on covariance of SAM return type and contravariance of SAM
> > parameter types, then overload resolution could use this relationship as a
> > last resort to try to disambiguate method resolution. You see that I didn't
> > mention the lambda expression - just the target SAM types. How initial
> > selection of "possible method candidates" is performed can be totaly
> > independent of this "soft-subtype" relationship.
> >
> >
> > Regards, Peter
> >
> >
>