That's why I suggested we might consider introducing an annotation
(called e.g. @GStringLiteralToString) which allows to switch this
behavior, together with an explicit syntax (e.g. S"..." / G"...") for
forcing a string literal to give a String/GString.
The S"..." / G"..." syntax could potentially also be used to unify
string literal variants and allow to support less often used variants,
by adding paramters, e.g.:
def groovySourceLine = S(escape:false,interpolate:true,end:'%&!§')"final
x="\n$xVal" // sets x to "\n" (newline) char + xVal.toString()"%&!§
Cheers,
mg
On 13.09.2018 21:05, MG wrote:
Hi Alessio,
nothing wrong with that, same as for the other, more explicit options:
final String x = 'abc'
String s0 = "x=$x"
def s1 = (String) "x=$x"
def s2 = "x=$x" as String
def s3 = "x=$x".toString()
But I believe Jochen is right in saying that people expect
def s4 = "x=$x"
to give a String, which of course it currently does not:
[s0, s1, s2, s3, s4].eachWithIndex { final o, final int i ->
println "$i) ${o.getClass()}: $o"
}
0) class java.lang.String: x=abc
1) class java.lang.String: x=abc
2) class java.lang.String: x=abc
3) class java.lang.String: x=abc
4) class org.codehaus.groovy.runtime.GStringImpl: x=abc
Cheers,
mg
On 13.09.2018 10:11, Alessio Stalla wrote:
Jochen,
what's wrong with
String s = "this is a GString literal"
for people who want a String?
If the problem is type inference, then in
def s = "this is a GString literal"
s could be inferred to be a String, while in
GString s = "this is a GString literal"
s would be a GString. Similarly for parameters and return values. If
you want a GString or pass a GString to a method, you get a GString,
otherwise a String. No need to change the semantics of the GString
class itself.
On Thu, Sep 13, 2018, 10:01 Jochen Theodorou <blackd...@gmx.org
<mailto:blackd...@gmx.org>> wrote:
Am 12.09.2018 um 13:59 schrieb mg:
> 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) ?
they expect it to be a literal to return String. Us being able to
assign
a GString to a String does not improve that impression
> 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.
yepp, was actually a goal. GString was supposed to be like a
subclass of
String. But I never considered that people may not expect
subclasses of
String.
> The question is, where does that lead us... ?
I think we need a way similar to GString literals to construct
strings.
Either something new, or change GString to something else
bye Jochen
