By the way you only need "final goo = ..." No need for 'var' in between.
(and for me 'final' doesn't seem too long to type) :-) On Sun, Jul 22, 2018 at 11:10 PM MG <[email protected]> wrote: > 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]> 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]> 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 >> >> >> >> > > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Twitter: @glaforge <http://twitter.com/glaforge>
