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)
