groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suderman Keith <suder...@anc.org>
Subject Re: Closure does not see field when setting value
Date Fri, 11 Nov 2016 02:28:26 GMT

> 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 = 1
// Added to the binding so it will be visible in the entire program.
x = 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] <x-msg://9/user/SendEmail.jtp?type=node&node=5736614&i=0>>
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 = 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 = 1" is supposed to work out of the box. You could 
> 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 
> http://mrhaki.blogspot.de/2016/01/groovy-goodness-customising-groovy.html <http://mrhaki.blogspot.de/2016/01/groovy-goodness-customising-groovy.html>
and 
> this 
> http://mrhaki.blogspot.de/2014/04/groovy-goodness-define-compilation.html <http://mrhaki.blogspot.de/2014/04/groovy-goodness-define-compilation.html>
might 
> be interesting to you 
> 
> bye Jochen 
> 
> 
> 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
<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 <applewebdata://987C1DDC-37CE-4029-8049-D3D881F239B9>.
> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> 
> View this message in context: Re: Closure does not see field when setting value <http://groovy.329449.n5.nabble.com/Closure-does-not-see-field-when-setting-value-tp5736534p5736614.html>
> Sent from the Groovy Users mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html>
at Nabble.com.


Mime
View raw message