John Wilson schrieb:
> This is a follow on to the "avoid boxing" thread.
>
> Let's assume, for the moment, that the JDK contains an infinite number
> of interfaces in the java.lang.reflect.dispatch package. An example of
> these looks like this:
>
> interface Ivoii {
> void fvoii(Object p1, int p2, int p3);
> }
> i.e. the interface has a single method and the spelling of the name of
> the interface tells you the name and the signature of the method (v =
> void, o = Object, i = int, b = byte, x = boolean, etc.)
something like that was also mentioned in the Gafter Closure proposal in
his Blog. Function Types or something like that did he name it.
> I think these would be pretty handy for dynamic language implementers.
I agree, it could be pretty handy, but...
> For example, if I was dynamically generating a MetaClass for each
> class I could make it implement one of these interfaces for every
> different message signature on the class (plus two extra Object
> parameters for the name of the method and the instance).
...The major problem with code generating parts in the MetaClass I met
so far is class loading. If you want to do a direct call to
Foo#foo(X,Y), then you may do this:
myAccessor = new Ivooo(){
void fvooo(Object o1, Object o2, Object o3) {
Foo foo = (Foo) o1;
foo.foo((X)o2,(Y)o3));
}
}
Now the problems comes with in what classloader to place this class? Yo
may or may not have access to the class loader that was used for Foo. In
Groovy we had the Reflector and it was using a child to the ClassLoader
in which the class was defined in. If the ClassLoader behaves normally,
then nothing bad will happen. At that time we had the disadvantage of
needing an interface form the Groovy lib and if two Groovy where active,
then it was possible, that the normal classloading would load the wrong
one, causing class cast exceptions for our Reflector, when casting the
generated Reflector class to its interface. This version has the
advantage of using the system loader to generate and access the
interface, so there shouldn't be a problem with this.
Besides that you only need to have a classloader that returns the same
class if you ask the loader for a certain class. Which means, there is
still some risk involved here.
But besides that... won't this do almost the same as MethodHandles? Only
that for MethodHandles you won't need to generate any classes.
[...]
> No that for this usage to work I need to implement up to three
> interfaces for every call signature on the class. As the call cannot
> tell the type of result it wants then if foo was declared as:
>
> int foo(int a, int b, int c)...
>
> we would have to implement Iiooiii, Ioooiii and Ivooiii when int, a
> boxed int and nothing was returned in each case.
that means having method that are equal in name and parameter types.
They only differ in the return type..in the same class? Now I know Java
couldn't have this, but who cares about that.. so it should work, as the
JVM selects by using the whole signature
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
