Jochen,
[...]
> the point was about migrating Java code to Groovy though - the reason
> why we have many constructs in Groovy we do not really need.
>
> [...]
>> What if there's a case when someone /would/ want a limited recursion?
>>
>> def getX() { some_condition?this.x:1 }
>>
>> That said, an error would be infinitely better than the current behaviour :)
>
> then call a method that does this and do the recursion on that method.
> If we call about migrated Java code, where Groovy idioms have been used,
> then you will not see "getFoo(){ return this.foo; }" or "private String
> foo;", you will see "String foo" and all problems are solved. My concern
> is really solely about the migration story, of Java code executed in Groovy.
I see and do understand, for I moved precisely this way tens-of-thousands of
old Java lines into Groovy myself, and was bitten in tender parts repeatedly by
things like e.g.,
boolean foo() {
return
true;
}
:)
That said, still it seems to me sort of at the unlucky side to cripple
Groovy-written-in-Groovy just so that the Java-to-Groovy transition goes more
smoothly.
Alas, I can't see a really good solution. Nevertheless, as I wrote before
(a) if getFoo() { this.foo } yields an error, it would be IMO infinitely better
than the current behaviour;
(b) nevertheless, it is still a breaking change, for getBar() { this.foo }
would in future call getFoo, whilst in the past it accessed the instance
variable directly, and that can break some legacy code as well.
The fact it would happen just in some special cases and with less probability
does not really help, either: those are the most ugly bugs of all.
All the best,
OC
