I also have a C/C++ background, and would also (still) like to have true
const ;-)
However, Java/Groovy final was never intended to be const, it declares a
const reference/pointer in C++ speak, and using final instead of def has
zero disadvantages, but multiple advantages (which I have already listed
multiple times here).
And if
fin goo = new Goo()
in Groovy is short for
final var goo = new Goo() // final Goo goo = new Goo()
no one would need to "code as if object(s) are final", but could just
make them final with zero overhead, compared to using either def or var
(and for immutability there is the new improved Groovy immutable support).
Cheers,
mg
On 22.07.2018 20:23, Suderman Keith wrote:
-1
Coming from a C/C++ background that has `const` I typically do not use
final because it does not give me a truly final (const) object and
users can still do:
final object = new SomeMutableObject()
object.mutateMe();
That just rubs me the wrong way. So as Pau says below, I typically
skip the final keyword, but code as if object(s) are final/const as
needed.
Keith
On Jul 22, 2018, at 1:53 AM, Paul King <[email protected]
<mailto:[email protected]>> wrote:
I am probably -1 right now on a new keyword when I think the existing
one works just fine.
One reason some Groovy folks might not use final more frequently is
because it has
historically (up until 2.4.x) been ignored by Groovy for local
variables. Java
also ignores final at runtime for local variables but that doesn't
matter for a statically
compiled language. Have a look at the bytecode using javap -v from
this Java program:
public class Hello {
public void method1() {
final Object o1 = new Object();
}
public void method2() {
Object o2 = new Object();
}
}
You will notice that the bytecode for method1 and method2 is identical.
Groovy 2.5 does a better job of detecting final for local variables.
It does it
in a similar sort of way to Java - at compile time. I'd be inclined
to wait and
see how this added support (plus @AutoFinal) affects usage.
The other discussions I have seen around not using final are around
style.
The 'final' modifier is particularly good at stopping the practice of
mutating some
variable mid-way through a long method in a confusing way. Agile
practices
discourage long methods, functional style discourages mutating variables
and codenarc can be used to some extent to catch bad behavior. So some
advocate omitting the final keyword but coding as if it was there to
obtain
more succinct, easier to read code. Now that we have @AutoFinal, I am
not sure that we need to aggressively further promote its usage but
rather
watch how usage changes in the short term.
Cheers, Paul.
On Sun, Jul 22, 2018 at 7:50 AM MG <[email protected]
<mailto:[email protected]>> wrote:
Hi guys,
I have been wondering for a while whether Groovy developers use
"def"
even if a variable is actually is "final" not only because every
Groovy
example code uses "def", but also because "final" as a word is
longer
than "def".
Therefore I propose to introduce the shortcut "fin" for "final"
in Groovy.
e.g. to support
class Goo {
fin String name
fin Goo gooParent
Goo(fin String name, fin Goo gooParent) { ... }
String gooGoal(fin x) {
fin y = 2*x
fin int z = x + y
}
}
Cheers,
mg
