> On Nov 9, 2016, at 4:53 PM, Krzysztof Kowalczyk > <[email protected]> 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.
