On Apr 30, 2008, at 12:48 PM, John Wilson wrote:
> This removes the need for boxing/unboxing and really should not lead
> to an excessive number of interfaces being generated.
That schema of interfaces is about the same as is being proposed for
java closures by Neal Gafter.
It's not too many for the JVM, though there are too many of them to
know by name, hence Neal's function type syntax. The compromise with
object types (which are quantified as generic type variables) leads
to inserted casts. The casts can sometimes be a performance hit
(hence the JVM's use of strongly typed reference arguments).
Underneath the N interfaces there are M (M>N) classes, one for each
target method. With method handles, for M target methods, you have M
little objects, not M classes. M classes is excessive, whether or
not you control the number N of call-signature interfaces.
More thoughts on reflect.Method:
There's a compatibility problem with making reflect.Method
polymorphic: It is final. There are ways to fudge that, such as
making the constructor JVM-private.
There's a performance problem with making reflect.Method the direct
receiver of an invoke, since Method is a very rich class; they are
probably 10x larger than a minimal method handle. The effort of
constructing one (even if you make some stuff lazy) goes far beyond
the intrinsic cost of naming a method.
But reflect.Method could contain a function type object ("closure"):
{PrintStream,int,int=>void} caller = mymethod.getCaller();
caller.invoke(System.out, 0, 30);
And, in turn, the closure could use method handles under the cover to
provide direct access, without the need for M classes. There would
be N closure-to-method-handle implementations. Each implementation
would invoke an underlying method handle with the right signature.
Or (I don't know if it could be made to work, but it's worth thinking
about) method handles could interoperate more tightly with closures,
by having each individual method handle somehow take on the
appropriate function interface type.
-- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
