1 Jan 2011 01:21
Re: [groovy-dev] Any plan to integrate G++ into Groovy?
Am 31.12.2010 23:40, schrieb Jon Cox: [...] > How up-to-date is: http://groovy.codehaus.org/MOP+2.0+ideas > and what's the timeline? timeline is the problem atm. It is still quite up to date. Some parts got implemented already. > Also, can you& Alex comment on what potential synergies/tensions > exist between groovy's roadmap and that of the groovy++ extension? Well, the basic part is that Groovypp is trying to do everything static if possible, while Groovy basically comes from the different direction. Ideally we meet in the middle and be happy. But if performance is the deciding factor, then you cannot easily move from the static world. Let us for example take a builder. Of course I can statically compile a builder. But that means I have to make every method call basically go to the invokeMethod of some object that then does the dispatch. This is usually slow, because the JVM cannot make this kind of call very fast. Additionally, what about methods that have the same name as a call you used in the builder? If you want to make it static with still going through the dispatcher object, then you have to give that some kind of ability to check if that method is available on the this-object and react accordingly. But if you compiled it as a direct call, it would be so much faster. And the other version even increases the problem. Now let us not take a builder, let us make this a closure that is called very often and the closure wants to call a method outside. Following the guidelines of current groovy you could intersect those methods using a delegate and an resolving strategy and without setting this at compile time. All in all the problem is that you somehow have to transport this(Continue reading)
RSS Feed