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> 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> 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
>>
>
>
>
