Forgot the list the first time.
On Thu, Aug 24, 2017 at 8:44 PM, Paul King <pa...@asert.com.au> wrote:
>
>
> On Wed, Aug 23, 2017 at 8:32 AM, MG <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
>>
>>
>>
>>
>
