I think these changes to the static compiler would be good to have, yes.
Am 14.09.2018 um 15:08 schrieb Alessio Stalla:
mg,
I'm perfectly ok with s4 in
def s4 = "x=$x"
being a String. What I'm not ok with is to change the semantics of
GString itself to accomodate for this specific case and others, as
proposed in the original mail.
What I suggest is:
* DO change the type inference of the static compiler for string literals.
* DO change the way literals are interpreted so they produce a String
in the general case and only produce a GString when assigned to a
GString or passed as a GString parameter to a method or cast to GString.
* DON'T change how GString instances work at runtime.
On Thu, 13 Sep 2018 at 21:20, MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:
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
