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 Fri, 14 Sep 2018 21:26:28 GMT
What proposed changes to the static compiler (which would not also apply 
to the dynamic compiler) do you guys mean ?

import groovy.transform.CompileStatic

@CompileStatic
GString gs(GString gs) { return gs }

@CompileStatic
String s(String s) { return s }

@CompileStatic
void gstringLiteralCheck() {
     final String x = 'abc'

     String s0 = "x=$x"
     def s1 = (String) "x=$x"
     def s2 = "x=$x" as String
     def s3 = "x=$x".toString()
     def s4 = "x=$x" // Proposed change: Should be String under static 
and dynamic compilation
     def s5 = s("x=$x")

     GString gs0 = "x=$x"
     def gs1 = (GString) "x=$x"
     def gs2 = "x=$x" as GString
     def gs3 = "x=$x" // Proposed change: Should be String under static 
and dynamic compilation
     def gs4 = gs("x=$x")

     println "\nString:"
     [ s0, s1, s2, s3, s4, s5 ].eachWithIndex { final o, final int i -> 
println "s$i) ${o.getClass()}: $o" }

     println "\nGString:"
     [ gs0, gs1, gs2, gs3, gs4 ].eachWithIndex { final o, final int i -> 
println "gs$i) ${o.getClass()}: $o" }
}

gstringLiteralCheck()


String:
s0) class java.lang.String: x=abc
s1) class java.lang.String: x=abc
s2) class java.lang.String: x=abc
s3) class java.lang.String: x=abc
s4) class org.codehaus.groovy.runtime.GStringImpl: x=abc
s5) class java.lang.String: x=abc

GString:
gs0) class org.codehaus.groovy.runtime.GStringImpl: x=abc
gs1) class org.codehaus.groovy.runtime.GStringImpl: x=abc
gs2) class org.codehaus.groovy.runtime.GStringImpl: x=abc
gs3) class org.codehaus.groovy.runtime.GStringImpl: x=abc
gs4) class org.codehaus.groovy.runtime.GStringImpl: x=abc



On 14.09.2018 18:39, Jochen Theodorou wrote:
> 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 <mgbiz@arscreat.com 
>> <mailto:mgbiz@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 <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