I agree that the two cases you provide shouldn't change. I believe what Daniel is describing might best be considered as an optimisation for the eager case. Rather than having a GString object with an array of "constant" Strings and an array of "constant" Values, when this case is determined, it could instead be replaced by a String. You would lose the ability to modify the GString after creation, e.g. in your example, eagerGString.values[0] = 3.
On Sat, Sep 8, 2018 at 9:26 PM Paolo Di Tommaso <[email protected]> wrote: > I would like to raise a flag here. > > Stated the Groovy documentation a Gstring can be resolved both in a eager > and lazy manner: > > def number = 1 def eagerGString = "value == ${number}"def lazyGString = > "value == ${ -> number }" > assert eagerGString == "value == 1" assert lazyGString == "value == 1" > > number = 2 assert eagerGString == "value == 1"assert lazyGString == "value > == 2" > > > > > http://groovy-lang.org/syntax.html#_special_case_of_interpolating_closure_expressions > > The example you are reporting should *already* be reasolved eagerly and I > can agree that it can be confusing. > > However the ability to resolve a GString lazily it's a very important > Groovy feature for DSL builders. Wipe it out would have a serious impact > (read destroy) on existing frameworks that rely on that feature. > > > Cheers, > Paolo >
