SAM conversion and overload resolution

[Alex Buckley]

Clever idea, we'll look into it.

Of course, the pairs of SAM types related by soft-subtyping (because the 
"underlying" function types are related by function-subtyping) actually 
forms quite a small set in comparison with the Cartesian product of the 
set of SAM types with itself. Many legal overloadings are ambiguous for 
a given call site, whether the formal parameter(s) is a SAM type or not:

interface SO { void invoke(String x, Object y); }
interface OS { void invoke(Object x, String y); }

class SOOS implements SO, OS {  // Legal
   public void invoke(String x, Object y) {}
   public void invoke(Object x, String y) {}
}
new SOOS().invoke("hello", "world"); // Ambiguous

void say(SO x) {..}
void say(OS x) {..}  // Legal
say( #(String s1, String s2){..} ); // Ambiguous

Alex

On 8/2/2010 4:03 AM, Peter Levart 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
>