groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Possible New Groovy Features... - Auto final-ize
Date Tue, 22 Aug 2017 22:32:02 GMT
Hi Paul,

On 21.08.2017 04:30, Paul King wrote:
> Support making all method/ctor parameters final by default through 
> "autofinal" Groovy compiler flag:
>      1. Foo(int x, String s) { // final keyword is auto added to all
>         parameters, if compiler flag is set, i.e. this automatically
>         becomes Foo(final int x, final String s)
>         this.x = x; this.s
>         }
>         Rationale: Even if Groovy source samples use def instead of
>         final a lot, parameters (and variables) are, according to my
>         experience, most of the time actually final in practice (In
>         the few cases where one needs to modify a parameter, it can
>         immediately be assigned to a variable). This feature would
>         reduce the source code clutter that comes from the need to
>         qualify parameters as final all the time.
> You can already leave off the "clutter" and apply a CodeNarc rule[1] 
> to detect "bad" style.

you are not a big fan of using final, I gather ;-)
When I picked Groovy for the framework I am developing, I started 
writing code in the typical Groovy style used e.g. on the Groovy webpage 
and mrhaki: def everywhere, no final. But at some point the C++ 
developer in me kicked in, and I started to ask myself, why final was 
not used instead of def, since in 99.999% of cases, no reassignment of 
variables or parameters occurs ? Apart from making the code easier to 
read & safer, it also allows compiler optimizations (and in the absence 
of a true const-keyword, at least for fundamental data types it has the 
same effect). So I started using final, and reapplying it to the code I 
wrote before. For methods with a large number of parameters this makes 
the method definition really long, and does not really improve 
readability. So auto-applying final imho really makes sense, at least in 
my case (but I am convinced it would for most Groovy developers, if it 
is easily available).

> Also, it would be an easy task to create an @AutoFinal local transform 
> which could then be automatically applied using a compiler customizer. 
> I think going further with a dedicated compiler flag would be a later 
> step if such a local transform became extremely popular.

Never found the need to do my own AST transforms in Groovy - do you 
maybe have a pointer to a current tutorial on how to get started for me 
? Since you mentioned macros in your reply, I first went "Do we have 
these in Groovy ?", then I found I checked out the 2.5 macro description 
- do you think it would be worth waiting for 2.5 to become stable to be 
able to use macros for this functionality ?


View raw message