jastrachan | 14 Jun 14:36 2004

Re: [groovy-dev] static dispatch, was [groovy-user] Groovy Performance 20-90% of Java?

Just stepping back for a moment and looking down from 30,000 ft.

The invokeMethod() mechanism was a simple hook to allow folks to 
intercept dynamic method invocations and do clever things. It was only 
ever intended for use by the Groovy runtime when doing dynamic method 
dispatch. e.g. if you write a Groovy bean and turn it into bytecode and 
pass it to some Java code, the Java code typically will not see any of 
the cleverness thats done in the invokeMethod() call.

e.g. if we did this in Groovy

class Foo {
     doSomething() {
	println "Hello"

     invokeMethod(String name, Object[] args) {
	if (name == "doSomething") {
	    println "Clever Stuff"
	else {
	    metaClass.invokeMethod(this, name, args)

Then in Groovy

x = new Foo()

would print "Clever Stuff"

however in Java, calling this method would print "Hello"

So following the principle of least surprise, if we do static method 
dispatch in Groovy, shouldn't it work just like Java? i.e. if I did 
this in Groovy...

Foo x = new Foo()

would print "Hello"

I really like the idea of using static method dispatch when folks want 
to and getting the performance benefits from that. I'm wondering if we 
should support invokeMethod() as an interceptor; it seems to me that if 
folks really wanna do method interception which works at the binary / 
bytecode level (and so works in Java code and when doing static method 
dispatch) that we need to do bytecode weaving instead (overloading 
methods & calling pre/post code blocks etc).

On 2 Jun 2004, at 13:42, Mark C. Chu-Carroll wrote:
> On Jun 2, 2004, at 6:37 AM, John Wilson wrote:
>> On 2 Jun 2004, at 00:17, Mark C. Chu-Carroll wrote:
>>> On Jun 1, 2004, at 4:14 PM, John Wilson wrote:
>>>> Another idea:
>>>> If the base Groovy object had a method called invokeViaReflection 
>>>> (String name, Object[] args). This is the way that methods would be 
>>>> invoked if invokeMethod fails to do something special. 
>>>> MyGroovySubclass would provide its own implementation of 
>>>> invokeViaReflection to ensure that the super versions of the 
>>>> overridden methods were invoked.
>>> We're thinking pretty alike on this. My latest idea was something 
>>> very similar to this, where
>>> part of the default implementation of invokeMethod would be 
>>> separated into a different function, which could be overridden 
>>> separately.
>>> So, for example, the default implementation of invokeMethod would be:
>>> 	public Object invokeMethod(String name, Object[] args) {
>>> 		...
>>> 		return dispatchOrdinaryMethod(String name, Object[] args);
>>> 	}
>>> 	public Object dispatchOrdinary(...) { current standard dispatch 
>>> code }
>>> Then, when we generate a class with methods deferring to 
>>> invokeMethod, we generate a
>>> new version of dispatchOrdinary which invokes the generated methods 
>>> through super.
>> Looks good, Mark.
>> Does dispatchOrdinaryMethod need to be public?
> No. In fact, it definitely should not be.
> 	-Mark
>> John Wilson
>> The Wilson Partnership
>> http://www.wilson.co.uk
> Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center
> *** The Stellation project: Advanced SCM Research
> ***      http://stellation.eclipse.org
> *** Work: mcc@.../Home: markcc@...