Hi OC,
1. Is there a reason you cannot put your "well-tested inner code" in a
seperate method, thereby making the code cleaner and avoiding the
name clash problem altogether ? In any case that is not a strong
argument in my eyes: Just copy & paste the code into a seperate
editor and s
MG,
the idea is very plain:
- if you don't need to nest same-named variables, there's no harm, you just
don't do that, and all's well and swell — the danger you do that inadvertently
and mess up your code is nonzero, but extremely small;
- if you happen to need that — typically, if you are copy
Hi Eric,
my take inline:
On 02/12/2020 17:34, Milles, Eric (TR Technology) wrote:
Traditional "for" (first example) and ARM "try" (last example) support
local variable declarations that are scoped to the statement. In
light of the upcoming "instanceof" enhancement in Java, I was thinking
a
Hi OC,
I think that generally speaking, hiding/masking an outer variable like
that is a quite undesireable coding style, so I like the current Groovy
behavior (even if it deviates from C, evidently - I never used code like
that in C, so I did not even know it was valid ;-) ).
What specific u
Hello there,
when touching this stuff, it would be extremely desirable primarily to fix the
scoping/obscuring of same-named variables, which Groovy at the moment does
wrong, same as the demented Java thing:
===
89 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q
org.codehaus.groovy.contr
Maybe the "if" could forward declare the name(s) like this when not relying on
Groovy truth:
if (def x; (x = ...) != null) {
}
-
if (def x = ...) { // tests Groovy truth in this form; may be wrapped in parens
to check something else about "x"
}
Traditional "for" (first example) and ARM "try" (last example) support local
variable declarations that are scoped to the statement. In light of the
upcoming "instanceof" enhancement in Java, I was thinking about possible
alternatives for declaring local variables that have statement scope.
fo
