Re: [groovy-dev] Pragmatic Groovy Development and Project Management

On 25 Jan 2005, at 10:37, John Wilson wrote:
> On 25 Jan 2005, at 10:00, Russel Winder wrote:
>> I feel very worried by the increasing implication that Classic Groovy
>> and New Groovy are different things.  My assumption was that the work 
>> on
>> the new parser was serving two purposes:
>>
>> 1.  A focus for the JSR work needed to bring a formal definition of 
>> the
>> Groovy language into being.
>>
>> 2.  To remove all the cruft from the Groovy language.
>>
>> If there are actually two different languages here then this needs to 
>> be
>> made explicit, i.e. that JSR-Groovy is a new and different language to
>> Groovy.
>>
>>
>
> I certainly believe that New Groovy is a significantly different (and 
> worse) language than Old Groovy
>
> As I understand things (and there is so little information available I 
> could be mistaken here)
>
> 1/ The delegate mechanism is being removed from Closure. This means 
> that the current Builder mechanism, Expando, GStringTemplateEngine and 
> XML-RPC will stop working.

The delegate on closures was a complete hack to create builders and 
leads to complete dynamic scope of variables. We need to fix this & put 
static scoping in place; so at compile time we know where a name is 
meant to come from (the outer class, the builder etc)

You can still implement your own delegate mechanism on a closure if you 
wish & we will put in place a builder mechanism in its place.

> 2/ The introduction of optional parentheses for methods taking no 
> parameters makes it impossible for the compiler to distinguish between 
> a method invocation and a property access on a untyped value. This 
> seems to me to require a complete rethink of how GPath works.

We need to clarify this. The tests in the TCK right now assume that 
parens are required to disambiguate between a property and a method. 
i.e.

collection.size

would work, but if you had a size() method and a size property, you'd 
have to use

collection.size()

to explicitly use the method

> 3/ Various Perl like variable decorators are being introduced in an 
> attempt to disambiguate cases introduced by the language changes.

Huh?

> 4/ Various breaking changes are being introduced in the way dynamic 
> method dispatch is applied to typed variables.

AFAIK I've always said that method dispatch should work the same 
whether static or dynamic typing is used - the only real difference is 
(i) the compiler can warn of typeos on methods and (ii) the 
implementation could use the static typing to generate better more 
efficient bytecode

> In addition a breaking change has already been made to the way dynamic 
> method dispatch is applied to untyped variables (e.g. toString cannot 
> now be processed by invokemathod())

What was this change?

> These changes have lead to me abandoning all work using Groovy as the 
> stuff I was working on would simple not work in new Groovy.

Thats a shame. Given we've not even got to discuss the builder stuff 
yet while we tie down the guts of the language, I'd hope your decision 
was premature & you'd reconsider when we've added the builder stuff 
back - but if not, good luck in the future John, its been a pleasure.

James
-------
http://radio.weblogs.com/0112098/