From users-return-3746-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Tue Sep 4 01:41:38 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 46C7D180647 for ; Tue, 4 Sep 2018 01:41:38 +0200 (CEST) Received: (qmail 64885 invoked by uid 500); 3 Sep 2018 23:41:37 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 64875 invoked by uid 99); 3 Sep 2018 23:41:37 -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; Mon, 03 Sep 2018 23:41:37 +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 D71C9C8545 for ; Mon, 3 Sep 2018 23:41:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.989 X-Spam-Level: * X-Spam-Status: No, score=1.989 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=asert-com-au.20150623.gappssmtp.com 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 Oaui3newAf08 for ; Mon, 3 Sep 2018 23:41:35 +0000 (UTC) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id C4CBE5F3AC for ; Mon, 3 Sep 2018 23:41:34 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id h4-v6so1833160edi.6 for ; Mon, 03 Sep 2018 16:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asert-com-au.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=ZwFJMjCaTtjmWYTHYv070AjCIKkekiBHvoqWC6HwT9Q=; b=Xl7idg61nKogjjfLf3csHLDJul/DlqB///fpqMqtEKrcTnuxGMeCg8VV+jm9vaXC4h yl+FWeUQEpRmgCxGP0EN3Qi2AmM9Ov3eqtZyOivq0rZ1tr0Hur80CrJQUhwk9mGtltkn wOAJFnp5obgJEUXQrlCcQkI4A8qPtes0ULrUpNw2f+C9dWPZTOEf4Y4yQJzochGSapYb En1RU0fYyJBTNdx3cRK2rA4vU+bkHXU6xwEhGjxWbjPrDFVQKYW1kv60WeOgv6pU2jyW FvUOUfQ6gbUT305daQR4DpRoNRvSlUtJDlWfsUuC0S2lshzlILRTcxWud9iT3krxRUzu 36oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=ZwFJMjCaTtjmWYTHYv070AjCIKkekiBHvoqWC6HwT9Q=; b=XbNVwcoT8sXckALjQkHVuDPYLfkGFyA++6WuF7YHdPsifbNNVsK1+yYgEahubDfdMk htI7LOEo3Kf7WU09iIOBwtiDtMGgmMoqFTr75VQgCjhSRVmSG/snYPco+6ldKmnhuRRl IRoJKRnPi4xDHKiTa/KOI9l5LzmtQZiuhUAqZ7+IntsbBWqF2+d4BgkUzUIWM5QNP7Om X6py3LswkSlv5Id7wsESoNQCLEUVyDetQBKz79eLucrO3ALyNHoi/SXJKN9NBFBXNWJv lgR/1qWbg4PtZHkEjQ3cYiih360Js6YlrleGGTI2yL3gOENkIy+8dnsLq4g+hzynaopr uxgw== X-Gm-Message-State: APzg51BUIXdAS/jZT375STLxFDWTJkyu9mNcazjeqNB+mIiFL48XQt0F 4JGAZV4zu259hPvfTzx/qnIQh6PCPpye2m6QxRBjRiZeU9M= X-Google-Smtp-Source: ANB0VdZ8mTSteLPITHpW57F1Caj+lHiApRWAF7BY9ggbZPvgacr6GCKG7vLrsVKDyhpyY1mYrrnV2eAkN8FNEKdLwdA= X-Received: by 2002:aa7:c314:: with SMTP id l20-v6mr33120377edq.53.1536018094343; Mon, 03 Sep 2018 16:41:34 -0700 (PDT) MIME-Version: 1.0 References: <98fdd40b-548e-27ae-5235-f044bfe707f0@arscreat.com> In-Reply-To: <98fdd40b-548e-27ae-5235-f044bfe707f0@arscreat.com> Reply-To: paulk@asert.com.au From: Paul King Date: Tue, 4 Sep 2018 09:41:23 +1000 Message-ID: Subject: Re: @CompileStatic void method returns null ? To: users@groovy.apache.org Content-Type: multipart/alternative; boundary="000000000000e1dca00575001448" --000000000000e1dca00575001448 Content-Type: text/plain; charset="UTF-8" Calling void methods is fine. Expecting a result is the point in question. For dynamic Groovy, you can't always tell which case you have: class Foo { def bar() { 42 } void baz() { } } def method(boolean condition, delegate, meth1, meth2) { if (condition) delegate."$meth1"() else delegate."$meth2"() } println method(true, new Foo(), 'bar', 'baz') // 42 println method(false, new Foo(), 'bar', 'baz') // null Here, "method" is expecting to return some value that happens to be the last expression, i.e. the result of the if/then/else expression, so we return null in such cases. Cheers, Paul. On Tue, Sep 4, 2018 at 7:38 AM MG wrote: > What I meant was: What sense does letting void methods be called make > for the dynamic case, i.e. the dynamic compiler ? From a programmer's > perspective, i.e. what is a programming use case for that > feature/behavior, in dynamic Groovy ? > > Of course I can do the following in dynamic Groovy: > > // Groovy 2.5.0 > class Goo { > //void nogoo() { return 123 } // Dynamic Groovy compiler: > RuntimeParserException: Cannot use return statement with an expression on a > method that returns void > void nogoo() { 123 } > } > > final goo = new Goo() > > println "original: goo.nogoo()=${goo.nogoo()}" > > goo.metaClass.nogoo = { return 456 } > > println "mopped: goo.nogoo()=${goo.nogoo()}" > > > Which will build, run, and output > > original: goo.nogoo()=null > mopped: goo.nogoo()=456 > > i.e. returning 456 from a void method in the second case. > But if I am using a library that includes the Goo class, why would I > ever expect a return value from the nogoo method (and therefore call > it), considering its return type is void ? And if I control the Goo > class myself, why would I not just change its return type to int or def ? > > Cheers, > mg > > > On 03.09.2018 22:36, Jochen Theodorou wrote: > > On 03.09.2018 17:13, mg wrote: > >> But in what scenario does the dynamic behavior make sense ? > > > > for a static compiler? none other than being compatible > > > > bye Jochen > > > > --000000000000e1dca00575001448 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Calling void methods is fine. Expect= ing a result is the point in question.

For dynamic Groo= vy, you can't always tell which case you have:

class Foo {<= /div>
=C2=A0 def bar() { 42 }
=C2=A0 void baz() { }
}

def method(boolean condition, delegate, meth1, = meth2) {
=C2=A0 if (condition) delegate."$meth1"()
=C2=A0 else delegate."$meth2"()
}

<= /div>
println method(true, new Foo(), 'bar', 'baz') // = 42
println method(false, new Foo(), 'bar', 'baz')= // null

Here, "method" is expecting to = return some value that happens to be the last expression, i.e. the result o= f the if/then/else expression, so we return null in such cases.
<= br>
Cheers, Paul.


On Tue, Sep 4, 2018 at 7:38 AM MG <mgbiz@arscreat.com> wrote:
What I meant was: What sense does letting= void methods be called make
for the dynamic case, i.e. the dynamic compiler ? From a programmer's <= br> perspective, i.e. what is a programming use case for that
feature/behavior, in dynamic Groovy ?

Of course I can do the following in dynamic Groovy:

// Groovy 2.5.0
class Goo {
=C2=A0=C2=A0=C2=A0=C2=A0 //void nogoo() { return 123 } // Dynamic Groovy co= mpiler: RuntimeParserException: Cannot use return statement with an express= ion on a method that returns void
=C2=A0=C2=A0=C2=A0=C2=A0 void nogoo() { 123 }
}

final goo =3D new Goo()

println "original: goo.nogoo()=3D${goo.nogoo()}"

goo.metaClass.nogoo =3D { return 456 }

println "mopped: goo.nogoo()=3D${goo.nogoo()}"


Which will build, run, and output

original: goo.nogoo()=3Dnull
mopped: goo.nogoo()=3D456

=C2=A0=C2=A0i.e. returning 456 from a void method in the second case.
But if I am using a library that includes the Goo class, why would I
ever expect a return value from the nogoo method (and therefore call
it), considering its return type is void ? And if I control the Goo
class myself, why would I not just change its return type to int or def ?
Cheers,
mg


On 03.09.2018 22:36, Jochen Theodorou wrote:
> On 03.09.2018 17:13, mg wrote:
>> But in what scenario does the dynamic behavior make sense ?
>
> for a static compiler? none other than being compatible
>
> bye Jochen
>

--000000000000e1dca00575001448--