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...
Ma;-)rkus
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 <pa...@asert.com.au
<mailto:pa...@asert.com.au>> wrote:
On Wed, Aug 23, 2017 at 8:32 AM, MG <mg...@arscreat.com
<mailto:mg...@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
