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 Fri, 25 Aug 2017 01:03:16 GMT
Hi Paul,

I was just referring to your "You can already leave off the "clutter" 
and apply a CodeNarc rule[1] to detect "bad" style", which seemed to 
poke fun at my suggestion - and which I did not quite get: What use 
would a rule be, if having the clutter that unavoidably comes from 
having "final" everywhere is exactly what the rule would enforce ?-)

Apart from that I totally get and expect the Devil's advocate approach 
from your side, I would do the same. If I have a proposal, I'd better 
expect you to poke it and be prepared to defend it.

Thank you for your suggestions on where to look for info on the local 
AST transform.
Where can I download "Groovy in Action" ?
Just kidding...

On 24.08.2017 14:08, Paul King wrote:
> Forgot the list the first time.
> On Thu, Aug 24, 2017 at 8:44 PM, Paul King < 
> <>> wrote:
>     On Wed, Aug 23, 2017 at 8:32 AM, MG <
>     <>> wrote:
>         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 ;-)
>     It's not a case of being a fan of a particular style. Groovy
>     supports final using the final keyword and we'd want a very good
>     reason to change that now. So I am just taking the Devil's
>     advocate point of view saying that the breaking change and
>     difference to Java are possibly too big given what is currently
>     supported. If we were starting a language from scratch and cared a
>     little less about being somewhat similar to Java, it might be a
>     totally different story.
>         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 ?
>     For a tutorial, I don't have anything that googling "groovy create
>     local AST transform" wouldn't give you. The online docs and Groovy
>     in Action would be my picks. I'd suggest an AST transform over a
>     macro for this use case. I'd also add that Groovy's final variable
>     analyser itself (a new feature in 2.5) still has a few unfinished
>     parts if you are looking for something that needs doing.
>     Cheers, Paul.
>         Cheers,
>         Markus

View raw message