groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Date Sat, 08 Sep 2018 12:05:56 GMT
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 <paolo.ditommaso@gmail.com>
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
>

Mime
View raw message