From dev-return-5117-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Sun Jul 22 20:24:12 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 5228218062F for ; Sun, 22 Jul 2018 20:24:11 +0200 (CEST) Received: (qmail 8839 invoked by uid 500); 22 Jul 2018 18:24:10 -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 8829 invoked by uid 99); 22 Jul 2018 18:24:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Jul 2018 18:24:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 548C1C60A0 for ; Sun, 22 Jul 2018 18:24:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=vassar.edu Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id lTcr9fKi4tpr for ; Sun, 22 Jul 2018 18:24:05 +0000 (UTC) Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id CB5825F439 for ; Sun, 22 Jul 2018 18:24:04 +0000 (UTC) Received: by mail-qt0-f182.google.com with SMTP id h4-v6so14597547qtj.7 for ; Sun, 22 Jul 2018 11:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vassar.edu; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=N9wNxmE/otcNXSTzkwzVU/kYma514K7hs5GCzZqN91Y=; b=eO6zj0NY+j6XlHD4h3zkDSkE9wB+3zm+NIeUnUvg+bP/4pqp1yJJV7o1wL8cp88LGv VzHHfRoggVt79jjOIpq1WHp+cSNqdclMpiODcnu9l7lBn9PhsORSUEuwzRD/xrsxKVOu HJA2MK4R6fBteEAU5GlR9CzsjQsdkkzGyJcGI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=N9wNxmE/otcNXSTzkwzVU/kYma514K7hs5GCzZqN91Y=; b=EaE3Ji2svFAIfqGFSBivhquLvxfB9XGDerEioojliSLHDaeQi3BiXrw+su+siIYYoQ zSuQ0eFQTYNloWeLKynZHb1vrjyxamxy4N40by3ZDVrXQDivbaIqpbjAHbdqT8Ik+sdB f3qay6oDzVgOBzE6pYVHzGVEy4mAor11xACR/hbAATwlPbKNpUv45B7YdL8vXLJN6nGC UIsfW2+miYX8gmUo1GfFAMJzNbKK4CBEexzC8XxWeoCD5EeXnlm40Q9H7rNX2exs+5tZ Zzil2SAHwjFXllSbMKsNb36qjdwpZsr9o80+9oKC+MaWNE7PqTzK/KVA+4DoaSI72V/y k3JA== X-Gm-Message-State: AOUpUlHu+kZOGejpKcDoofkRIws0F92BH/1iuG48gnLM1Mo/t9rVnbCV ACXsuudVVpvZhGV6RSqIQlkQ5lS0GkM= X-Google-Smtp-Source: AAOMgpc9c/reAA1rzxnhfdmKW2QCv8ERF2JXohg85vtXkE+YkczEiiWvYJQkU2GvbBfB/na35nfIeg== X-Received: by 2002:a0c:f94e:: with SMTP id i14-v6mr8609128qvo.73.1532283837354; Sun, 22 Jul 2018 11:23:57 -0700 (PDT) Received: from [192.168.1.104] (daphmb0130w-ad03-160-245.dynamic.bellmts.net. [205.200.160.245]) by smtp.gmail.com with ESMTPSA id v187-v6sm4578872qka.73.2018.07.22.11.23.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 11:23:56 -0700 (PDT) From: Suderman Keith Content-Type: multipart/alternative; boundary="Apple-Mail=_69EB29E9-1BF7-4D88-BF7B-1610FE686672" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: fin Date: Sun, 22 Jul 2018 13:23:52 -0500 References: <1291b3a4-9204-d311-f005-bd2f32aae959@arscreat.com> To: dev@groovy.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) --Apple-Mail=_69EB29E9-1BF7-4D88-BF7B-1610FE686672 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -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 =3D 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: >=20 > I am probably -1 right now on a new keyword when I think the existing = one works just fine. >=20 > 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: >=20 > public class Hello { > public void method1() { > final Object o1 =3D new Object(); > } > public void method2() { > Object o2 =3D new Object(); > } > } >=20 > 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. >=20 > 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. >=20 > Cheers, Paul. >=20 >=20 > On Sun, Jul 22, 2018 at 7:50 AM MG > wrote: > Hi guys, >=20 > I have been wondering for a while whether Groovy developers use "def"=20= > even if a variable is actually is "final" not only because every = Groovy=20 > example code uses "def", but also because "final" as a word is longer=20= > than "def". > Therefore I propose to introduce the shortcut "fin" for "final" in = Groovy. >=20 > e.g. to support >=20 > class Goo { > fin String name > fin Goo gooParent > Goo(fin String name, fin Goo gooParent) { ... } > String gooGoal(fin x) { > fin y =3D 2*x > fin int z =3D x + y > } > } >=20 > Cheers, > mg >=20 >=20 >=20 --Apple-Mail=_69EB29E9-1BF7-4D88-BF7B-1610FE686672 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii -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 =3D 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 =3D new = Object();
}
public void = method2() {
Object o2 =3D 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 =3D 2*x
         fin int z =3D x + y
     }
}

Cheers,
mg




= --Apple-Mail=_69EB29E9-1BF7-4D88-BF7B-1610FE686672--