Forgot the list the first time.

On Thu, Aug 24, 2017 at 8:44 PM, Paul King <paulk@asert.com.au> wrote:


On Wed, Aug 23, 2017 at 8:32 AM, MG <mgbiz@arscreat.com> 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