On Tue, May 18, 2010 at 5:18 PM, John Rose <john.r.r...@oracle.com> wrote: > On May 18, 2010, at 12:59 AM, Rémi Forax wrote: > >> It's only useful when bridging JRuby and Java, > > It could also be useful for bridging language A to language B. > > For example, Clojure has a suite of Function interfaces. > > But the key use is as you say, for interoperating with the Java platform APIs.
One important question for me is how multi-method interfaces would be handled. I had originally tried to use Scala's "Function" interfaces in Duby to represent closures, but they all have multiple abstract methods that must be handled completely differently. I'd need to provide my own superclass with default behavior or have a way to stitch together N handles for N abstract methods. And I agree about the language bridging...plus in the JRuby case, this actually makes Ruby to Ruby bridging easier: * We need a codebase that works on Java 6 * ...so we can't move our entire call path to using MethodHandle * ...so we need our own abstract "invoker" supertype * ...so being able to use that supertype with either generated impls or MethodHandle-provided impls makes it easier for us to support both indy and non-indy runtimes in the same implementation. Perhaps this also helps Java 7 closures work nicer by making it possible to have a generic Closure or Function superclass completely independent of java.dyn? Or by making it possible to implement (faster) Java reflection with fewer generic frames under the covers via a single abstract supertype populated by indy? Seems like a good addition, in any case, but especially once it's faster and more direct than reflect.Proxy :) - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
