Guillaume Laforge wrote:

I agree with Guillaume. Such a change would end up making Groovy not only less dynamic and "less Groovy", it would also make it internally inconsistent since adding a static type declaration would change what method a call dispatches to.

Part of the problem with introducing static typing that produces static method binding is that much of Groovy's power comes from its ability to override methods on a target type. Since the outward-facing static-typed method signature does not do an additional dynamic dispatch, statically binding to either a Groovy type's or a Java type's static method signatures (as in Alex's experiment) would mean that additional changes (metaprogramming et al) would not be seen by static call sites.

So ultimately, you'd have dynamic invocation for dynamic (untyped) code and static invocation for static typed code, and mixing the two would lead to different pieces of code calling different methods.

I'm positive Groovy can do better in the performance arena while still remaining fully dynamic, and I have lots of ideas for how to get there I'm willing to share and help with. But I think the value of a dynamic-typed language is in dynamic typing...so we shouldn't optimize for static typing, especially when it changes the invocation semantics of the language.