[groovy-dev] Experimental Metaclass Action Helper committed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Experimental Metaclass Action Helper committed

tugwilson
I have just added an directory called experimental to CVS HEAD.

This contains code which demonstrates how we could dynamically  
compile a class which could be used to implement the method dispatch  
and the attribute and property get/set actions for a MetaClass.

The real life implementation would generate bytecode but this  
generates Java. This makes debugging easier but makes using the code  
a little awkward. You have to run code to generate the Java, compile  
the Java by hand and then run a program which uses the class files.

It has a number of deficiencies:

1/ only method invocation is supported - the attribute and property  
support would be implemented in a similar manner I have just not had  
the time to implement it.

2/ the code to select between methods with the same name and number  
of parameters is not implemented - the first method is always chosen  
at the moment.

3/ it will not generate valid code for classes in the default package  
- this is a Java restriction - we could generate bytecode to do this.

There is a very simple test program included which generates a  
handful of java action support files. You can easily extend it if you  
want to se what it generates for other classes.

Please have a play with this if you can find the time. Rrror reports  
are most welcome:)



John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] Experimental Metaclass Action Helper committed

LARSON, BRIAN (SBCSI)
One note:  It is dependent on the 1.5 JDK because it uses the
getSimpleName() method on Class.

Also, at first glance it appear there needs to be a little more thought
around GC.  For example, I think the actionsInfoMap should probably be a
WeakHashMap.



-----Original Message-----
From: John Wilson [mailto:[hidden email]]
Sent: Monday, October 31, 2005 8:21 AM
To: [hidden email]
Subject: [groovy-dev] Experimental Metaclass Action Helper committed


I have just added an directory called experimental to CVS HEAD.

This contains code which demonstrates how we could dynamically  
compile a class which could be used to implement the method dispatch  
and the attribute and property get/set actions for a MetaClass.

The real life implementation would generate bytecode but this  
generates Java. This makes debugging easier but makes using the code  
a little awkward. You have to run code to generate the Java, compile  
the Java by hand and then run a program which uses the class files.

It has a number of deficiencies:

1/ only method invocation is supported - the attribute and property  
support would be implemented in a similar manner I have just not had  
the time to implement it.

2/ the code to select between methods with the same name and number  
of parameters is not implemented - the first method is always chosen  
at the moment.

3/ it will not generate valid code for classes in the default package  
- this is a Java restriction - we could generate bytecode to do this.

There is a very simple test program included which generates a  
handful of java action support files. You can easily extend it if you  
want to se what it generates for other classes.

Please have a play with this if you can find the time. Rrror reports  
are most welcome:)



John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Experimental Metaclass Action Helper committed

tugwilson

On 31 Oct 2005, at 15:01, LARSON, BRIAN (SBCSI) wrote:

> One note:  It is dependent on the 1.5 JDK because it uses the
> getSimpleName() method on Class.

good catch!

>
> Also, at first glance it appear there needs to be a little more  
> thought
> around GC.  For example, I think the actionsInfoMap should probably  
> be a
> WeakHashMap.
>


Yes I think this would be desirable. If an ActionsInfo instance is  
GCd it can be regenerated. The map is really just a cache.

Thanks for the comments, Brian.



John Wilson
The Wilson Partnership
http://www.wilson.co.uk