groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Failing to change the value of a Java variable from wihtin a Groovy script (potential issue?)
Date Tue, 05 Apr 2016 17:35:52 GMT

On 05.04.2016 18:23, Thierry Hanser wrote:
> Thank you for your explanations Jochen.
> Your assumption is correct except that I think you meant to say that *The subsequent
"println '2 = ' + x" will then get the value property instead of asking for the binding.*
since the value ('one') is the one from the unchanged variable/property 'x'.
> I am confused by the lack of symmetry in the handling of the binding/properties value.

That's because a script is not intended to be a class. In a script the 
binding is the important instance anything else is just a fallback. A 
simple example would be "this.class". If there is no "class" in the 
binding you get the result of getClass(), which is normally what you 
intend to get. On the other hand, if you did "foo=1", why would you 
expect setFoo() being called instead? You just set something in the 
binding, so why not get it from the binding?

> "print x" in a script will call getX() (if available) whereas "x = 'two'" will call setProperty()
which will add 'x' (if not present) to the binding but will not subsequently call setX().

That is write, but don't forget that "print x" will go through 
getProperty, which is written to ask the binding. So there is a symmetry 
with getProperty and setProperty, it just does not extend to getX and 
setX, because the implementation of the setter breaks that.

So the question is really if we should not first look for a setter and 
only use the binding for setting, if the setter is not available. 
Well... traditionally scripts don't really have a lot of setters, that's 
why it normally it does not matter. And if you need that kind of logic, 
you can still use a class in the script... normally... of course base 
script changed that story a bit, but then maybe it should redefine the 
binding logic in this case as well. That's fully up to the custom base 
class actually.

> As a result when you use the value of a property 'x' in a script you are guaranteed to
call getX() but if you assign a value to 'x' you are not guaranteed that setX() is called

wrong "x=1; print x" will get you the value from the binding. so getX() 
is not guaranteed to be called. and setX() is actually never called 
through a "x=1".. unless you did mean with static compilation

> This dissymmetry seems odd to me (and obviously leads to unexpected behaviour).
> Note that without static compilation the same dissymmetry is observed, however for some
reason the property 'x' is then properly updated but still without calling setX()

I would call that a bug in the static compilation. But I wonder how the 
static compiler is actually supposed to behave. It cannot know the 
values of the binding, thus it would need to compile against the setters 
and getters. It would then be wrong to ask the binding for anything, 
unless you do it directly. Which means all scripts using the binding 
normally won't compile statically. But hey, I think that is ok.

> I understand there are issues with the CompileStatic option. Do we know what level of
prioritization are these issues in the bigger Groovy roadmap?

we normally use only blocker, major and minor. A blocker is a bug you 
cannot work around easily. Since in your case you can call the setter 
instead, it would be no blocker. minor are bugs, that show more little 
inconsistencies. And major priority is the vast majority of the bugs. 
Sometimes we also use blocker to ensure it is in the next release... but 
we have gotten away from this.

bye Jochen

View raw message