2009/11/2 Charles Oliver Nutter <[email protected]>:
>
> On Mon, Nov 2, 2009 at 7:11 AM, Jochen Theodorou <[email protected]> wrote:
>> Oh you would wonder... In fact we call it optional typing in Groovy, but
>> it is really very much like gradual typing. Only the compiler is not
>> using the type information to speed up the program. We will change that
>> for Groovy 1.8.
>>
>> I should maybe try to explain a difference between the Java type system
>> and the one Groovy uses. In Groovy a method call on an object with Type
>> T is not limited to the methods declared for this type. Instead the
>> runtime type is used. Since Groovy supports overloading of methods too,
>> that means you cannot relay on information you find in the type, unless
>> it is a really a direct match. If you have an Object typed variable x
>> and do x.foo(), and the runtime type of x will be Foo, which has a foo()
>> method, then the call will succeed. Since we at compile time don't know
>> the type Foo, we cannot generate a direct method call for that. And now
>> optional typing in 1.8 will come into play. You can type the variable as
>> Foo and the compiler will be able to generate a direct method call on x
>> using Foo. Also in Groovy you don't need casts when you assign something
>> to a typed variable. Instead Groovy will add an implicit cast. This way
>> Groovy ensures, that the variable will contain an object of at least
>> that type all the time. It is like declaring an upper bound kind of (if
>> parents are above).
>
> Won't this break existing behavior? Currently, even if you declare a
> type, it will still dispatch based on the runtime set of methods for
> that type. So in your example, if I have replaced the foo() method on
> Foo with some other piece of code, will statically declaring my
> variables as type Foo dispatch to the original foo() method or the one
> I've replaced? This is the conundrum I face in Ruby, where we already
> can gather type feedback to know a variable is always X, but still
> need to check if X is being modified so our direct calls are valid.
> Some of this exists already in JRuby; if you call a numeric method
> directly against a Fixnum (boxed 64-bit integer), it will go straight
> in and even inline the logic. Upcoming compiler work will also start
> to add type and method guards to inlined/optimized versions of code.
> But the mutability of classes common to both Ruby and Groovy means
> unguarded direct calls will probably always be suspect.
It's a good question!
It's virtually impossible to do effective type inferencing with Groovy
semantics. E.G. with
int a = 1
int b = 2
def x = a + b
you have no idea of the type of x. Indeed if this code is executed at
the same time in two different threads x can end up being two
different types (because of Categories).
It's, at least theoretically, possible to do speculative execution of
some classes of Groovy expression and, if you can do a cheap test to
ensure that the operators have not been overloaded, you can get
execution speeds within an order of magnitude of straight Java.
I have never seen any way of doing unguarded direct method calls in
Groovy. It is possible to generate synthetic helper methods on a
compiled Groovy class which can be safely called directly but these
helper methods need to do checks before they can pass the call on to
the target method; so you are, in effect, doing guarded calls.
Because, in the general case, Groovy needs to examine the type of each
parameter at runtime before dispatching the method (because Groovy
supports a method dispatch mechanism very similar to Java's) this
requires another set of guards: E.G.
class C {
int foo(int p) {
return p + 2
}
}
int x = 1
int y = 2
new C().foo(x + y)
there is no way you can do a direct dispatch to foo on the instance of
C. Firstly you don't know the type of the result of x + y and secondly
you don't know what methods have been been monkey patched onto
instances of C.
The method dispatch problem is really difficult in Groovy because of
the need to implement Java style method selection based on the type of
the actual parameters (In Groovy it's based on the type of the actual
parameter not the declared type of the variable holding the actual
parameter - but that makes it even more difficult).
Still, Jochen has been thinking about this for longer than I have - so
maybe he's seen something I've missed.
John Wilson
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
