Hi OC,
in my experience shadowing:
1. Leads to hard to read code.
2. Can evidently happen by accident, and then it can lead to hard to
spot errors - so yes, if it is supported, I might be forced into
that situation.
So still for keeping things the way the are ||-)
Cheers,
mg
Am 08.09.2025 um 00:25 schrieb OCsite:
MG,
nobody ever forced you to shadow local variables if you don't like
that. You can do whichever of your approaches listed below freely.
What's wrong is to force the other people, who consider shadowing a
good idea, not to.
All the best,
OC
On 8. 9. 2025, at 0:08, MG <[email protected]> wrote:
Hi OC,
@Shadowing local variables is a normal and very reasonable thing
which worked perfectly and without a glitch from the Pascal up, or
perhaps even Algol, I am not quite sure, it's far far ago :)
Forbidding it is wrong, for it prevents e.g. copy/pasting small code
snippets which just happen to contain an inner variable (most
typically something like for (int i...) which just happens to be used
in the code into which the snippet goes as well. The developer is
then forced to change the old and well-tested code renaming the
variable, which for one takes time which can be used much better
elsewhere, what's worse, it brings a danger the changes would cause
new bugs:
1. As someone who always thought allowing shadowing of local
variables was a bad idea, I would challenge that statement ||-)
2. As for your example of copy & pasting a code snippet:
1. I paste the snippet into a text editor to search & replace
the colliding variable name in that scenario, manually
confirming every replace.
1. I have done this many times over the years, and that has
never lead to the introduction of any bugs.
2. In addition, since all the names used in the snippet will
typically not follow ones own coding/naming convention,
this must be done in any case, most of the time.
2. Alternatively one could always put the snippet into a
seperate method, to avoid any name collisions...
Cheers,
mg
Am 07.09.2025 um 15:20 schrieb Ondra Cada:
Jochen,
On 7. 9. 2025, at 13:05, Jochen Theodorou <[email protected]> wrote:
On 05.09.25 18:10, OCsite wrote:
[...]
===
def foo // [1]
...
for (def foo in ....) // would not use [1], would scope a new
variable instead
for (foo in ...) // would use [1]
===
If you are cosy with breaking backward compatibility, well, you
should do /this/ change, not /that/ one which breaks it for no
benefit at all.
the first for-loop must not compile
It does, since [1] happens to be a property :)
because it would invalidate how local variable scoping works in
general: we do no allow shadowing of local variables, every local
variable name must be unique!
Quite. That's another very bad thing which should be fixed to work
the way normal languages (which obviously does not include Java[*])
always did.
Shadowing local variables is a normal and very reasonable thing
which worked perfectly and without a glitch from the Pascal up, or
perhaps even Algol, I am not quite sure, it's far far ago :)
Forbidding it is wrong, for it prevents e.g. copy/pasting small code
snippets which just happen to contain an inner variable (most
typically something like for (int i...) which just happens to be
used in the code into which the snippet goes as well. The developer
is then forced to change the old and well-tested code renaming the
variable, which for one takes time which can be used much better
elsewhere, what's worse, it brings a danger the changes would cause
new bugs :(
Note also this creates another weird inconsistence — with the
default it, Groovy does support shadowing all right; try e.g.,
===
2.times {
println "outer it=$it"
666.each {
println "inner it=$it"
}
println "outer it back to $it, as it should!"
}
===
I'ts completely strange and counter-intuitive that soon as I use an
explicit declaration (e.g., just { int it ->, to make sure the
type's right, without touching the inner code inside of the
closure), I'm SOL.
That's patently wrong. This is precisely one of those many things
which Java designers did not do right. [*]Groovy is here to fix Java
design bugs and inconveniences — if Java was perfect, after all,
Groovy would never have a reason to exist —, and it very definitely
should fix this one as well. This fix would not even break any
backward compatibility; it would simply allow code which sometimes
might be highly beneficial and so far was forbidden.
But that is besides the point of if the for-loop spawns a new local
scope or not.
Quite :) That's why, in my original example, the local scope
shadowed a property and not another local variable :)
Thanks and all the best,
OC
