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 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,


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 = 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 and
this might
be interesting to you

bye Jochen

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from Closure does not see field when setting value, click here.

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