groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Possible New Groovy Features... - Auto final-ize
Date Fri, 25 Aug 2017 02:15:24 GMT
On Fri, Aug 25, 2017 at 11:03 AM, MG <mgbiz@arscreat.com> wrote:

> 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 ?-)
>

I definitely wasn't trying to poke fun at any suggestions. Many people
consider changing parameters halfway through a long method can be confusing
and lead to obscure bugs when the person reading your code wasn't expecting
the change. From my agile background days there were two schools of thought
on dealing with that issue (mostly in Java land in those days). One is that
you should have final everywhere because then the compiler will stop the
"bad" style. The second is that having final everywhere adds lots of
"clutter" and makes the code less succinct. Leave final off but don't
change those parameters anyway - and back it up with a checkstyle rule that
breaks the build if you ever do. Advocates of the second style would go on
to say that if you have a method that is so long that you might get lost
knowing whether a parameter has changed or not, well you have a method that
is way too long! :-)


> 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" ?
>

Actually, I think an @AutoFinal transform might be a good addition. I'm
happy to work on that with you if you like.

Cheers, Paul.



> 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 <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
>>>
>>>
>>>
>>>
>>
>
>

Mime
View raw message