I am reading the Groovy closure documentation in https://groovy-lang.org/closures.html#this. Having a question regarding with GString behavior.
- Closures in GStrings
The document mentioned the following:
Take the following code:
def x = 1
def gs = "x = ${x}"
assert gs == 'x = 1'
The code behaves as you would expect, but what happens if you add:
x = 2
assert gs == 'x = 2'
You will see that the assert fails! There are two reasons for this:
a GString only evaluates lazily the toString representation of values
the syntax ${x} in a GString does not represent a closure but an expression to $x, evaluated when the GString is created.
In our example, the GString is created with an expression referencing x. When the GString is created, the value of x is 1, so the GString is created with a value of 1. When the assert is triggered, the GString is evaluated and 1 is converted to a String using toString. When we change x to 2, we did change the value of x, but it is a different object, and the GString still references the old one.
A GString will only change its toString representation if the values it references are mutating. If the references change, nothing will happen.
My question is regarding the above-quoted explanation, in the example code, 1 is obviously a value, not a reference type, then if this statement is true, it should update to 2 in the GString right?
The next example listed below I feel also a bit confusing for me (the last part) why if we mutate Sam to change his name to Lucy, this time the GString is correctly mutated?? I am expecting it won't mutate?? why the behavior is so different in the two examples?
class Person {
String name
String toString() { name }
}
def sam = new Person(name:'Sam')
def lucy = new Person(name:'Lucy')
def p = sam
def gs = "Name: ${p}"
assert gs == 'Name: Sam'
p = Lucy. //if we change p to Lucy
assert gs == 'Name: Sam' // the string still evaluates to Sam because it was the value of p when the GString was created
/* I would expect below to be 'Name: Sam' as well
* if previous example is true. According to the
* explanation mentioned previously.
*/
sam.name = 'Lucy' // so if we mutate Sam to change his name to Lucy
assert gs == 'Name: Lucy' // this time the GString is correctly mutated
Why the comment says 'this time the GString is correctly mutated? In previous comments it just metioned
the string still evaluates to Sam because it was the value of p when the GString was created, the value of p is 'Sam' when the String was created
thus I think it should not change here?? Thanks for kind help.
These two examples explain two different use cases. In the first example, the expression
"x = ${x}"creates aGStringobject that internally storesstrings = ['x = ']andvalues = [1]. You can check internals of this particularGStringwithprintln gs.dump():Both objects, a
Stringone in thestringsarray, and anIntegerone in thevaluesarray are immutable. (Values are immutable, not arrays.) When thexvariable is assigned to a new value, it creates a new object in the memory that is not associated with the1stored in theGString.valuesarray.x = 2is not a mutation. This is new object creation. This is not a Groovy specific thing, this is how Java works. You can try the following pure Java example to see how it works:The use case with a
Personclass is different. Here you can see how mutation of an object works. When you changesam.nametoLucy, you mutate an internal stage of an object stored in theGString.valuesarray. If you, instead, create a new object and assigned it tosamvariable (e.g.sam = new Person(name:"Adam")), it would not affect internals of the existingGStringobject. The object that was stored internally in theGStringdid not mutate. The variablesamin this case just refers to a different object in the memory. When you dosam.name = "Lucy", you mutate the object in the memory, thusGString(which uses a reference to the same object) sees this change. It is similar to the following plain Java use case:You can see that
list2stores the reference to the object in the memory represented bynestedvariable at the time whennestedwas added tolist2. When you mutatednestedlist by adding new numbers to it, those changes are reflected inlist2, because you mutate an object in the memory thatlist2has access to. But when you overridenestedwith a new list, you create a new object, andlist2has no connection with this new object in the memory. You could add integers to this newnestedlist andlist2won't be affected - it stores a reference to a different object in the memory. (The object that previously could be referred to usingnestedvariable, but this reference was overridden later in the code with a new object.)GStringin this case behaves similarly to the examples with lists I shown you above. If you mutate the state of the interpolated object (e.g.sam.name, or adding integers tonestedlist), this change is reflected in theGString.toString()that produces a string when the method is called. (The string that is created uses the current state of values stored in thevaluesinternal array.) On the other hand, if you override a variable with a new object (e.g.x = 2,sam = new Person(name:"Adam"), ornested = new ArrayList()), it won't change whatGString.toString()method produces, because it still uses an object (or objects) that is stored in the memory, and that was previously associated with the variable name you assigned to a new object.