Re: Static dispatch and call semantics

On 19 Nov 2004, at 17:09, Chris Poirier wrote:

> And while I'm on it, I think invokeMethod() is a nightmare, as
> implemented.  I would prefer the freedom of something much more
> constrained (I've always loved that paradox).  As it is, invokeMethod()
> can override /everything/ the language defines, and on /any/ object.  I
> think that's a recipe for disaster, to be honest.  If it is desirable 
> to
> allow classes to redefine the class model, then something like a
> metaobject protocol should be developed, so that users can make 
> reliable
> predictions about how any given piece of code will behave.  That said,
> my not liking something as fundamental as invokeMethod() may indicate
> that I'm just not Groovy.  

I totally agree. The invokeMethod() originally came about as a helper 
method for Java folks to invoke methods on Groovy objects. Then it got 
used as an optimisation for bytecode generation to invoke methods on 
Groovy objects. Then folks started using it to do wacky things.

I think we probably need some simple hook to allow folks to do wacky 
things if they want - but also some marker interface is required to say 
that you're writing some wacky dynamic proxy thing - as the current 
invokeMethod() mechanism makes things far too wierd. So invokeMethod() 
needs fixing.

James
-------
http://radio.weblogs.com/0112098/