Charles Oliver Nutter wrote:

Actually, we have static typing in Groovy:

def foo (String s) {1} def foo (Object o) {2}

String a = "test" Object b = a def c = a def d = b

// with Groovy style static typing assert foo(a) == 1 assert foo((Object)b) == 2 assert foo(c) == 2 assert foo((Object)d) == 2

Which suggests two questions:

1. Since this has been in there for a while and hasn't caused problems in existing code bases, would allowing a different syntax for the same thing cause problems? Right now we can say "in this particular use, treat variable X as class C, even if it's of a class derived from C." The proposed change would say "wherever this variable is used, treat it as class C." That means the declaration which determines the semantics is removed from where its used, but that's no different from any other declaration. For example, "a = 23" can fail if a is of type, say, Map. And that declaration could be far away from the assignment line, but people seem to handle that alright.

2. Could we use the existing syntax to do more at compile time and less at runtime? I think the answer at the moment is "no," because the types are just given to the metaclass, and in general its an uncomputable problem to tell what the metaclass will be at compile time.

But what if the programmer could annotate a class to say "all instances of a given class use the same metaclass," and then have a way for the metaclass to tell the compiler when a method could be determined at compile time?

For example, if the Metaclass has a resolveMethod() method, then at compile time we could instantiate the Metaclass with a no-arg constructor and call resolveMethod() with the given types. If it returns a method, we could insert that call directly. If it returns None, we go back to inserting the normal ScriptBytecodeAdapter.invokeMethod() call.

What do people think?

Best, Martin

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email