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:10:12 GMT
Yes, not changing the implementation/semantics of the existing GString 
class, and instead considering changing (potentially switchable through 
an annotation) the semantics of "GString literals"* is the premise of 
all my mails in this thread.

Would be interested to hear what other Groovy devs think about this 
subject ?

Cheers,
mg

*Quotes, since what is now a GString literal will then become a pure 
"String literal with interpolation support", as in other languages.



On 14.09.2018 15:08, Alessio Stalla wrote:
> 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