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

On 31 May 2004, at 20:53, Miles Parker wrote:
> Chris Poirier wrote:
>
>> It's not just a code generation problem.  We have to make a few policy
>> decisions on how static typing will work.  Once that is all worked 
>> out,
>> the changes to code generation will probably be fairly small, but we
>> can't really make them until the design is worked out.  There is also
>> the matter of optimizations complicating debugging, which is still
>> ongoing.
>
> Ya, that makes sense - my personal frustration is that I just don't 
> want to go down this road and then discover that I can't get the 
> preofmrance I need. This is prob. semantic, but I don't see this as an 
> optimization issue per se, but a fairly deep language design issue, so 
> I do appreciate your caution.
>
> Any ideas about how that might go? One idea I would like to commend to 
> folks is the way that Dylan accomplished all of this -- all methods 
> were by default dynamic, but you could 'seal' any method you wanted 
> for static dispatch. Elegant and simple idea.

BTW Dylan was a large influence on the semantics on Groovy.

The current mechanism I'd assumed when starting Groovy was that if a 
variable/parameter/field was given a type, then it would use static 
method dispatch & it'd be a compile error to call a method thats not 
available at compile time. (i.e. act like normal static typing). If the 
type information was excluded then dynamic typing would be used.

So

String x = "hello"

// static dispatch
x.length()

// dynamic dispatch
y = x
y.length()

Though we need to ponder about this a little through the JSR to check 
its still valid & doesn't have any holes in it - e.g. the 
invokeMethod() method as discussed elsewhere in this thread.

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