hg: mlvm/mlvm/jdk: meth: add proxy maker for closures

[Charles Oliver Nutter]

On Tue, May 18, 2010 at 5:18 PM, John Rose <john.r.rose at 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