But do they expect GString to be immutable, or do they expect a GString literal
to return a String instance (ie for toString() being called implicitely on it) ?
I would expect the latter. At least I was not aware that the Groovy "GString
concept" is actually based on a GString class when I started out with Groovy -
using def everywhere together with the fact that Groovy toString|s GString|s
when a String is expected do a great job of obfuscating that.
The question is, where does that lead us... ?
-------- Ursprüngliche Nachricht --------Von: Jochen Theodorou
<[email protected]> Datum: 11.09.18 11:20 (GMT+01:00) An: MG
<[email protected]>, [email protected] Betreff: Re: [Proposal] GString is
implemented eager and treated as normal
String since groovy 3.0.0
Am 11.09.2018 um 01:59 schrieb MG:
> Hi Jochen,
>
> could you be more precise about where you see the problem(s) in your
> example:
>
> 1) That Wrapper is not an immutable class, and you can therefore change
> its state after creation ?
> 2) That GString $-expressions (outside of "${-> ...}") do not capture
> the expression, but the result of evaluating the expression (which
> oftentimes will be an Object referece) ?
> 3) That GString is not immediately evaluated to its String representation ?
> 4) ... ?
The problem is user expectations. Many do not expect GString to be
mutable, since they do not use it as a templating solution or something
compareable. I think we should offer something here. That does not have
to be GString in syntax at all.
Or we align more with Javascript tempalating and make GString immutable.
bye Jochen
