groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Local variable declaration enhancements -- statement scoping
Date Thu, 03 Dec 2020 00:34:33 GMT
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 search & replace all clashing variable names, or put it
    into a seperate method temporarily and use your IDE's renaming
    support to change the variable names - this should take less than a
    few minutes, and how often do you really encounter that scenario in
    practice ?
 2. You example of using it in closures makes no sense to me, since "it"
    in a closure always refers to the one closure argument, so a new
    closures it will always hide any enclosing closures it. At the same
    time "it" in closures is typically only used for very compact
    closure bodies, often single statetments, so there is never any
    danger of confusing what the it refers to.
 3. This is in my experience absolutely not the case for any larger
    piece of code, so let's agree to differ on whether masking variables
    in general is a good idea or not :-)

Cheers,
mg


On 03/12/2020 00:24, OCsite wrote:
> 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 
>> <mailto: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