groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: fin
Date Sun, 22 Jul 2018 21:09:57 GMT
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 <paulk@asert.com.au 
>> <mailto:paulk@asert.com.au>> 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 <mgbiz@arscreat.com 
>> <mailto:mgbiz@arscreat.com>> 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
>>
>>
>>
>


Mime
View raw message