Sun 13 Oct 2013 06:50:20 AM UTC, original submission:
Notwithstanding bug #39047, there are still problems with overloaded methods with a boolean parameter.
(1) Consider Java file:
public class bar {
public void ff(java.util.List x) { System.out.println("s/x: "+x); System.out.flush();}
public void ff(boolean x) { System.out.println("b/x: "+x); System.out.flush();}
}
and Scheme file:
(define bb (bar))
(define x::integer 12)
(bb:ff x)
This doesn't work. The java.util.List methods is preferred as "possibly applicable", which fails at run-time, even though the boolean method should work.
Note it works if we comment out the List method, but we get a compile-time warning.
(2) Overload resolution at compile-time vs run-time is inconsistent. Consider:
(define wtr
(java.io.PrintWriter
(java.io.OutputStreamWriter (java.lang.System:.out) "UTF-8")))
(define (print-it)
(wtr:println "PRINT ME"))
(print-it)
((->java.io.PrintWriter wtr):flush)
This works if loaded in whole-module mode, but if we use --script (or -f) the boolean method is chosen, because it is earlier in the sort order when building a GenericProc.
A possible approach is to consider a method:
foo(boolean x)
as if it where two methods:
foo(boolean_strict x) // requires argument to be a boolean
foo(convert_to_boolean x) // convert argument to boolean
The former would be very specific and applicable only to booleans, just as in Java. The latter is very non-specific and applicable to all arguments - it would be views as "less specific" than Object.
|