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

What about indicating what type of dispatching is required in a Groovy 
object's metaclass (with a flag or a different subclass of Metaclass for 
those classes or metaclasses which override invokeMethod)?  Generated 
code could just check the metaclass to decide whether to call 
invokeMethod.  You can cache the metaclass to eliminate redundant calls 
to getMetaClass().  With some changes to the model, it might even be 
possible to bypass getMetaClass() for subclasses of GroovyObjectSupport 
and use the metaClass field directly.

This type of technique was first used AFAIK in Smalltalk by Alan Borning 
to implement multiple inheritence within a single-inheritence VM.

John Wilson wrote:

> I have raised a JIRA issue which proposes that a Groovy class cannot 
> subclass a Groovy class which does not implement invokeMethod and then 
> implement it (the same for get/set Property). It might be a good idea 
> to have a rule saying that a Groovy class can't subclass a Java class 
> which does not implement GoovyObject (other than Object, of course) 
> and then implement invokeMethod or get/set property (i.e. the compiler 
> adds final methods to the Groovy class unless the programmer provides 
> them explicitly)
>
> In the case of a Java class subclassing a Java class (other than 
> Object) and implementing GroovyObject there's not much that can be 
> done as far as I can see. I'd be perfectly happy if programmers were 
> that the dynamic calls would not be made if the object was cast to the 
> superclass in Groovy.
>
> Can you see any other way of making this safe?