From dev-return-5120-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Sun Jul 22 23:10:11 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B339918062F for ; Sun, 22 Jul 2018 23:10:10 +0200 (CEST) Received: (qmail 92151 invoked by uid 500); 22 Jul 2018 21:10:09 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 92141 invoked by uid 99); 22 Jul 2018 21:10:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Jul 2018 21:10:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id BC19A1A022D for ; Sun, 22 Jul 2018 21:10:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id rVQDlZS5QHtI for ; Sun, 22 Jul 2018 21:10:07 +0000 (UTC) Received: from mx16lb.world4you.com (mx16lb.world4you.com [81.19.149.126]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 610B95F41A for ; Sun, 22 Jul 2018 21:10:06 +0000 (UTC) Received: from [84.112.214.51] (helo=[192.168.0.28]) by mx16lb.world4you.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fhLc7-0006kK-JJ; Sun, 22 Jul 2018 23:09:59 +0200 Subject: Re: fin To: dev@groovy.apache.org, Suderman Keith References: <1291b3a4-9204-d311-f005-bd2f32aae959@arscreat.com> From: MG Message-ID: <1d1b0bc0-dcfe-6ef2-88e1-fb3326502728@arscreat.com> Date: Sun, 22 Jul 2018 23:09:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BB164DD55D8973B83E1F6502" Content-Language: en-US X-AV-Do-Run: Yes This is a multi-part message in MIME format. --------------BB164DD55D8973B83E1F6502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 > > 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 >> >> >> > --------------BB164DD55D8973B83E1F6502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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> 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> 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





--------------BB164DD55D8973B83E1F6502--