groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Date Thu, 13 Sep 2018 19:20:02 GMT
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 <blackdrag@gmx.org 
>> <mailto:blackdrag@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
>>
>


Mime
View raw message