groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OCsite <...@ocs.cz>
Subject Re: Local variable declaration enhancements -- statement scoping
Date Wed, 02 Dec 2020 23:24:29 GMT
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-pasting some well-tested inner
code into another method — you just do that and don't have to rename. And that's highly
desirable, for renaming is dangerous and error-prone: you rename once-too-many or once-too-less,
and hard-to-find errors ensue.

As for coding style, that's in the eye of the beholder, but in my own experience, it is considerably
better to keep the same approach — like i, j, k etc. for indices used in small loops etc.
— than using i here, i1 there, i2 in just another place, all messing up the code mightily,
without any proper reason — just forced by the compiler deficiency in proper nesting.

Incidentally, Groovy sort-of supports this with it: you can write

3.times { // works all right, which is, well... all right :)
  println "outer: $it"
  it.times {
    println "inner: $it all right"
  }
}

it is completely absurd and nonsensical that you can not rewrite the very and completely same
code with explicit variables:

3.times { n -> // does not work, which is wrong
  println "outer: $n"
  n.times { n ->
    println "inner: $n oops!"
  }
}

This “let's try to prevent the programmer shooting his own leg by crippling his gun” approach
of Java is actually a cause of infinitely more errors than those it prevents. We should leave
it to Java to cherish its terrible design howlers — and get rid of them in Groovy, in my
personal opinion :)

All the best,
OC

> On 2 Dec 2020, at 23:33, MG <mgbiz@arscreat.com> wrote:
> 
> 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 use case did you have in mind, where just renaming the inner variable to
i0, j, k, ... or the outer to index, idx, ... would not be the better solution ?
> (I use an informal coding style where I use variable names with a number at the end for
short term / loop / etc variables, and for parameters and variables who live throughout a
method or larger block I use no number postfix or longer names; the short name / long name
meta at least is quite common, I think)
> 
> Cheers,
> mg
> 
> 
> On 02/12/2020 18:13, OCsite wrote:
>> 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> <q.groovy
>> def i=0 // outer
>> println "i=$i (outer)"
>> for (int i=1 /* inner */;i<2;i++) println "i=$i (inner)"
>> println "i=$i (outer again)"
>> 89 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q
>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
>> /private/tmp/q.groovy: 3: The current scope already contains a variable of the name
i
>>  @ line 3, column 10.
>>    for (int i=1 /* inner */;i<2;i++) println "i=$i (inner)"
>>             ^
>> 1 error
>> 90 ocs /tmp>
>> ===
>> 
>> This is how it should work:
>> 
>> ===
>> 90 ocs /tmp> <q.c
>> #include <stdio.h>
>> int main() {
>>   int i=0;
>>   printf("i=%d (outer)\n",i);
>>   for (int i=1 /* inner */;i<2;i++) printf("i=%d (inner)\n",i);
>>   printf("i=%d (outer again)\n",i);
>>   return 0;
>> }
>> 91 ocs /tmp> cc -Wall q.c && ./a.out                     
>> i=0 (outer)
>> i=1 (inner)
>> i=0 (outer again)
>> 92 ocs /tmp> 
>> ===
>> 
>> Thanks and all the best,
>> OC
>> 
>>> On 2 Dec 2020, at 17:34, Milles, Eric (TR Technology) <eric.milles@thomsonreuters.com
<mailto:eric.milles@thomsonreuters.com>> 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 about possible alternatives
for declaring local variables that have statement scope.
>>>  
>>> for (int i = ...; ...) {
>>>   // i available
>>> }
>>> // i unavailable
>>>  
>>> for (x in y index i) { // from Gosu (http://gosu-lang.github.io/docs.html <http://gosu-lang.github.io/docs.html>)
-- an alternative to using eachWithIndex
>>> }
>>>  
>>> if (x instanceof T t) { // from Java 14+
>>> }
>>>  
>>> if (def x = ...) { // tests Groovy truth in this form; may be wrapped in parens
to check something else about "x"
>>> }
>>>  
>>> try (def ac = ...) {
>>> }
>>>  
>>> This e-mail is for the sole use of the intended recipient and contains information
that may be privileged and/or confidential. If you are not an intended recipient, please notify
the sender by return e-mail and delete this e-mail and any attachments. Certain required legal
entity disclosures can be accessed on our website: https://www.thomsonreuters.com/en/resources/disclosures.html
<https://www.thomsonreuters.com/en/resources/disclosures.html>
> 


Mime
View raw message