Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B2744200BC7 for ; Fri, 11 Nov 2016 03:28:57 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B056A160B10; Fri, 11 Nov 2016 02:28:57 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A855F160B01 for ; Fri, 11 Nov 2016 03:28:56 +0100 (CET) Received: (qmail 7466 invoked by uid 500); 11 Nov 2016 02:28:50 -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 7456 invoked by uid 99); 11 Nov 2016 02:28:50 -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; Fri, 11 Nov 2016 02:28:50 +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 459051A7BE5 for ; Fri, 11 Nov 2016 02:28:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.812 X-Spam-Level: **** X-Spam-Status: No, score=4.812 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, URI_HEX=1.313] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id zqIdH0GgV_Ta for ; Fri, 11 Nov 2016 02:28:48 +0000 (UTC) Received: from homiemail-a78.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 966F25F65A for ; Fri, 11 Nov 2016 02:28:47 +0000 (UTC) Received: from homiemail-a78.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTP id 9DC8148000A33; Thu, 10 Nov 2016 18:28:27 -0800 (PST) Received: from picard.home (pool-173-62-64-171.pghkny.fios.verizon.net [173.62.64.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: keith@suderman.com) by homiemail-a78.g.dreamhost.com (Postfix) with ESMTPSA id 36E4248000A30; Thu, 10 Nov 2016 18:28:27 -0800 (PST) From: Suderman Keith Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_00170482-B77C-4B45-BE9E-DAF5A88113E3" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Closure does not see field when setting value Date: Thu, 10 Nov 2016 21:28:26 -0500 In-Reply-To: Cc: users@groovy.incubator.apache.org To: users@groovy.apache.org References: <0734aad1-f900-2963-f2b4-4a8511167fc2@gmx.org> <8e4a988a-299f-7de8-bae9-75ae94dd01ca@gmx.org> <1478612873118-5736543.post@n5.nabble.com> <582218F5.7000709@gmx.org> <582369D0.5000801@gmx.org> X-Mailer: Apple Mail (2.3251) archived-at: Fri, 11 Nov 2016 02:28:57 -0000 --Apple-Mail=_00170482-B77C-4B45-BE9E-DAF5A88113E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 9, 2016, at 4:53 PM, Krzysztof Kowalczyk = wrote: >=20 > Thanks, >=20 > I understand why it is happening. I don't understand why someone would = want the binding to be created on the fly in such way. It is = counterintuitive for me. It has serious consequences and I don't see a = use case where I would want such behaviour (for the "set"). I use this "feature" extensively in my DSLs. Any DSL I write likely has = an "include" method that will parse an included script and run it. Then = in the included script I can have: // Only visible in the included script. def x =3D 1 // Added to the binding so it will be visible in the entire program. x =3D 1 Keith >=20 > I was thinking about using explicit base script declaration and = compile options. Both would require special action from the potential = user and second would not work with grape. So I was also thinking about = global ast transformation that checks if I have a script with my method = and then change the base class. This would look better but it would be = harder to explain, >=20 > Regards, > Krzysztof >=20 > On 9 November 2016 at 18:24, Jochen Theodorou [via Groovy] <[hidden = email] > = wrote: > On 08.11.2016 22:21, Krzysztof Kowalczyk wrote:=20 > > Ok, thanks.=20 > >=20 > > So that would make this.x reference works as expected but still x =3D = 1=20 > > would work in surprising way. Why to allow creation of new bindings = in=20 > > this way at all? Reading bindings, fine, but creating new? To share = them=20 > > with outside world?=20 >=20 > because a script "x =3D 1" is supposed to work out of the box. You = could=20 > always have a different script base class.=20 >=20 > > The behaviour is surprising to me in 2 ways:=20 > > First, I do create a new thing even though it "exists".=20 >=20 > Binding does not care what already exists.=20 >=20 > > Second, if I compile it in static way it will behave differently.=20 >=20 > and static compilation does not care about dynamic behaviours.=20 >=20 > > @CompileStatic should behave as I want (I guess), but I can't easily=20= > > apply @CompileStatic to a script, can I?=20 >=20 > This=20 > = http://mrhaki.blogspot.de/2016/01/groovy-goodness-customising-groovy.html = and=20 > this=20 > = http://mrhaki.blogspot.de/2014/04/groovy-goodness-define-compilation.html = might=20 > be interesting to you=20 >=20 > bye Jochen=20 >=20 >=20 > If you reply to this email, your message will be added to the = discussion below: > = http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting= -value-tp5736534p5736602.html = > To unsubscribe from Closure does not see field when setting value, = click here . > NAML = >=20 > View this message in context: Re: Closure does not see field when = setting value = > Sent from the Groovy Users mailing list archive = at = Nabble.com. --Apple-Mail=_00170482-B77C-4B45-BE9E-DAF5A88113E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 9, 2016, at 4:53 PM, Krzysztof Kowalczyk <kowalczyk.krzysztof@gmail.com> wrote:

Thanks,

I understand why it is happening. I = don't understand why someone would want the binding to be created on the = fly in such way. It is counterintuitive for me. It has serious = consequences and I don't see a use case where I would want such = behaviour (for the "set").

I use this "feature" extensively in my DSLs.  Any = DSL I write likely has an "include" method that will parse an included = script and run it.  Then in the included script I can = have:

// Only visible in the = included script.
def x =3D 1
// Added to the binding = so it will be visible in the entire program.
x =3D = 1

Keith




I was thinking about using explicit = base script declaration and compile options. Both would require special = action from the potential user and second would not work with grape. So = I was also thinking about global ast transformation that checks if I = have a script with my method and then change the base class. This would = look better but it would be harder to explain,

Regards,
Krzysztof

On 9 November 2016 at 18:24, Jochen Theodorou [via = Groovy] <[hidden = email]> wrote:
On 08.11.2016 22:21, Krzysztof Kowalczyk wrote:
> Ok, thanks.
>
> So that would make this.x reference works as = expected but still x =3D 1
> would work in surprising way. Why to allow creation = of new bindings in
> this way at all? Reading bindings, fine, but = creating new? To share them
> with outside world?

because a = script "x =3D 1" is supposed to work out of the box. You could=20
always have a different script base class.

> The = behaviour is surprising to me in 2 ways:
> First, I do create a new thing even though it = "exists".

Binding does = not care what already exists.

> Second, = if I compile it in static way it will behave differently.

and static = compilation does not care about dynamic behaviours.

> = @CompileStatic should behave as I want (I guess), but I can't easily
> apply @CompileStatic to a script, can I?

This=20
http://mrhaki.blogspot.de/2016/01/groovy-goodness-customising-groovy.html and=20
this=20
http://mrhaki.blogspot.de/2014/04/groovy-goodness-define-compilation.html might=20
be interesting to you

bye Jochen
=09 =09 =09

If you reply = to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting-value-tp5736534p5736602.html
=09 To unsubscribe from Closure does not see field when = setting value, click here.
NAML

=09 =09 =09
View this message in context: Re: Closure does not = see field when setting value
Sent from the Groovy Users mailing list archive at Nabble.com.

= --Apple-Mail=_00170482-B77C-4B45-BE9E-DAF5A88113E3--