Re: [VOTE] Add a shorthand "final var" keyword

[MG <mg...@arscreat.com>]

Hi Matti,

On 28/04/2020 19:29, mojo2012 wrote:
> 2. There are a lot of reasons to not have a variable declared as final
> (think about loops). Being forced to use another keyword to "un-final" the
> variable would break the sense of this whole discussion. And treating all
> local variables as final would pose a lot of issues too. I don't think that
> this is the way to go.

that prompted me to pull the plug and finally apply @AutoFinal in our 
project globally: I had to fix just 30 places in 240K lines of code to 
make the project build again. And all of these were laziness / bad code 
style on my part in old code parts, since I reassigned to method parameters.
And local variables in the project are 99.9...% explicitly declared 
final anyway, since reassignment to variables the way we program is 
exceedingly rare.
An in Groovy (or modern Java), due to its functional programming 
paradigm, there should be very few to no loop variables (in addition 
these could maybe automatically be exempt from @AutoFinal processing, 
depending on how much effort that takes to implement), so I think that 
this would actually be a valid approach.

> 3. I'm also fine with "fin" as I more care about the alignment (and
> therefore "optical consistency") than the actual letters to type :-D.
> Although it is rather uncommon choice :-D

Having ruled out "val" and "let", I tried to come up with something 
other than "fin", but it (still) seems like the only sensible choice to 
me, if one effectively wants a 3-letter alias for "final" (which is not 
going anywhere).
So, yea, uncommon - but if the existing ones are bad, the only choice is 
to come up with something new...

> Personally, I'd even go a little farther and deprecate "def name" and "final
> name" in favour of their java counterparts. I never quite liked these
> keywords (no offence) - although I know that this would break almost all
> legacy code.

"Step away from the "def", keep your hands were I can see them... !"

Joking aside: "def" is imho a good keyword for dynamic Groovy, where 
everything is supposed to be an GroovyObject (ironically even there 99% 
of all variables/parameters/fields are effectively final, but people 
still use "def" - which is why I suggested the fin = final alias the 
first time round).
In any case there is no way this is going to be changed, due to the 
reason you gave.

> Anyway, the idea to make it more java compatible sound good to me. To sum up
> you are suggesting that:
> * def is unchanged
> * final var/final def = fin/val/let -> changed to work like the java way

Yea:
def ... alias for (Groovy)Object
var ... RHS type inference*
fin ... alias for final var

Cheers,
mg

*Simple/primitive, not blackdrag-AI-style :-): type of RHS for 
expression (typically a class), method return type for methods (can be 
class or interface)