On 5/2/08, Jochen Theodorou <[EMAIL PROTECTED]> wrote:
>
> 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.
Yes, I think that this proposal is slighly simpler and less general.
>
>
> > 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.
I'm not quite sure I understand this problem.
When you are creating a MetaClass you have the Class instance so you
can get the classloader which loaded that class. Surely you can just
use a classloader which delegates to the classloader which loaded the
class to load the MetaClass?
>
> But besides that... won't this do almost the same as MethodHandles? Only
> that for MethodHandles you won't need to generate any classes.
Yes, the advantage if this proposal is that I can implement and deploy
it now (using a custom classloader and not using
java.lang.reflect.dispatch, of course)
>
> [...]
>
> > 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
No, the names are always distinct int (int) -> fii Object (int) - > foi
John Wilson
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
