John Wilson schrieb:
> On 5/2/08, Jochen Theodorou <[EMAIL PROTECTED]> wrote:
[...]
>> 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?
sure, you can. But when you execute your code, then it will cause the
loading of several classes that are used in the parent loader. And for
the method call not to end in an exception, you need to get the exact
same classes from the classloader. So if the loader does not behave as a
good little classloader should, then you are screwed.
[...]
>> > 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
ah, right... didn't realize that... very nice
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 jvm-languages@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
