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. > On the summit I did show that Groovy can be extremely slow for the > Fibonacci example. But that is because we first have to get loose of all > the synchronization stuff we currently do in the runtime. That is there > for a good reason, just that it does make Groovy slower even in the > single threaded cases. What synchronization stuff do you deal with in the fib example? Perhaps I missed some of that during your talk. JRuby currently does no synchronization at all during a simple algorithm like fib. Is it because you do not have your own set of core types, like Fixnum is our 64-bit numeric box? We are also exploring the near-term possibility of making JRuby allow arbitrary Object to pass through the system without a wrapper, and for that we'll start to find solutions to metaclass caching, etc. A mix of wrapped and unwrapped may be best: currently we pay a metaclass lookup cost only once, when the object enters Ruby, and from then on it's just a field access on the wrapper. - Charlie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
