Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

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

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

Thinking further along that line: A possible Groovy way to solve this might be 
through an annotation combined with explicit (G)String literal syntax varieties:
@GStringLiteralToString(true)class Goo {  String doGood0(final o) {    def s0 = 
"o=$o" // s0 is String    def gs0 = G"o=$o" // G"..." => gs0 is GString  }
@GStringLiteralToString(false)doGood1(final o) {    def gs1 = "o=$o" // gs1 is 
GString    def s1 = S"o=$o" // S"..." => s1 is String  }}
@GStringLiteralToString(true) could then be the default.
Cheers,mg
 Ursprüngliche Nachricht Von: mg  Datum: 
12.09.18  13:59  (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: [Proposal] 
GString is implemented eager and treated as normal
  String since groovy 3.0.0 
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) ?
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.
The question is, where does that lead us... ?
 Ursprüngliche Nachricht Von: Jochen Theodorou 
 Datum: 11.09.18  11:20  (GMT+01:00) An: MG 
, dev@groovy.apache.org Betreff: Re: [Proposal] GString is 
implemented eager and treated as normal
  String since groovy 3.0.0 


Am 11.09.2018 um 01:59 schrieb MG:
> Hi Jochen,
> 
> could you be more precise about where you see the problem(s) in your 
> example:
> 
> 1) That Wrapper is not an immutable class, and you can therefore change 
> its state after creation ?
> 2) That GString $-expressions (outside of "${-> ...}") do not capture 
> the expression, but the result of evaluating the expression (which 
> oftentimes will be an Object referece) ?
> 3) That GString is not immediately evaluated to its String representation ?
> 4) ... ?

The problem is user expectations. Many do not expect GString to be 
mutable, since they do not use it as a templating solution or something 
compareable. I think we should offer something here. That does not have 
to be GString in syntax at all.

Or we align more with Javascript tempalating and make GString immutable.

bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[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) ?
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.
The question is, where does that lead us... ?
 Ursprüngliche Nachricht Von: Jochen Theodorou 
 Datum: 11.09.18  11:20  (GMT+01:00) An: MG 
, dev@groovy.apache.org Betreff: Re: [Proposal] GString is 
implemented eager and treated as normal
  String since groovy 3.0.0 


Am 11.09.2018 um 01:59 schrieb MG:
> Hi Jochen,
> 
> could you be more precise about where you see the problem(s) in your 
> example:
> 
> 1) That Wrapper is not an immutable class, and you can therefore change 
> its state after creation ?
> 2) That GString $-expressions (outside of "${-> ...}") do not capture 
> the expression, but the result of evaluating the expression (which 
> oftentimes will be an Object referece) ?
> 3) That GString is not immediately evaluated to its String representation ?
> 4) ... ?

The problem is user expectations. Many do not expect GString to be 
mutable, since they do not use it as a templating solution or something 
compareable. I think we should offer something here. That does not have 
to be GString in syntax at all.

Or we align more with Javascript tempalating and make GString immutable.

bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Guillaume Laforge]

No, it's never been there, it's never been supported in Groovy.

Le mar. 11 sept. 2018 à 18:39, Jochen Theodorou  a
écrit :

>
>
> Am 11.09.2018 um 18:05 schrieb Paco Zarate:
> > [...]
> >
> > Is the R"..." Groovy old style notation still around?
>
> nope. actually I do not know when this was ever in use... I remember a
> different syntax. mabye it was in one of the old beta versions before
> beta-10
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

As far as I remember, closure have another old style notation too, e.g.  {x ,
y | x + y } ;-)


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

Am 11.09.2018 um 18:05 schrieb Paco Zarate:

[...]

Is the R"..." Groovy old style notation still around?


nope. actually I do not know when this was ever in use... I remember a 
different syntax. mabye it was in one of the old beta versions before 
beta-10


bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

> Is the R"..." Groovy old style notation still around?
modern groovy does not support the old style notation.

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

Please do not understand wrong. I am only saying that this is useless 
for Groovy... as was for example generics. That does not mean we will 
not support it. And since I do see usage for this in Java an people will 
surely start using it, I think we should support it as well without 
GString interpolation.


Am 11.09.2018 um 17:14 schrieb mg:
I also thought we already agreed on that. I do get where Jochen is 
coming from, however not supporting this less mainstream but certainly 
useful in certain scenarios Java syntax will imho not help with the 
problem that Groovy supports a large number of different (G)String 
literals with a non-unified syntax.


 Ursprüngliche Nachricht 
Von: Paul King 
Datum: 11.09.18 16:05 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: Re: [Proposal] GString is implemented eager and treated as 
normal String since groovy 3.0.0



IIUC, raw strings don't escape unicode as well as not supporting 
interpolation or backslash escaping.

I think we'll inevitably need to look at supporting it.

On Tue, Sep 11, 2018 at 9:16 PM Jochen Theodorou <mailto:blackd...@gmx.org>> wrote:




Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
 > I mean that Java.next’s syntax for raw strings does not support
variable
 > interpolation. My understanding is that groovy won't either.

we have actually 4 multiline string variants, of which 1 is not
supporting variable interpolation
http://groovy-lang.org/syntax.html#_string_summary_table

What the Java version does and we not, is having no interpolation for
escapes. We have the dollar-slashy-string to have a different escape
symbol, but without escapes (raw strings) is nothing we have.

And actually I don't think we need raw string literals in Groovy at
all... but that might be because I do not see good use for them beyond
regular expressions, and for those we have a solution in Groovy already.

bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paco Zarate]

http://openjdk.java.net/jeps/326 says:

A different delimiter was required to signify different interpretation
behavior. Other languages chose a variety of delimiters:

*Delimiters*

*Language/Tool*

"""..."""

Groovy, Kotlin, Python, Scala, Swift

`...`

Go, JavaScript

@"..."

C#

R"..."

Groovy (old style)

R"xxx(...)xxx"

C/C++

%(...)

Ruby

qq{...}

Perl

[...]

Is the R"..." Groovy old style notation still around?


On Tue, Sep 11, 2018 at 9:14 AM, mg  wrote:

> I also thought we already agreed on that. I do get where Jochen is coming
> from, however not supporting this less mainstream but certainly useful in
> certain scenarios Java syntax will imho not help with the problem that
> Groovy supports a large number of different (G)String literals with a
> non-unified syntax.
>
>  Ursprüngliche Nachricht 
> Von: Paul King 
> Datum: 11.09.18 16:05 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Re: [Proposal] GString is implemented eager and treated as normal
> String since groovy 3.0.0
>
>
> IIUC, raw strings don't escape unicode as well as not supporting
> interpolation or backslash escaping.
> I think we'll inevitably need to look at supporting it.
>
> On Tue, Sep 11, 2018 at 9:16 PM Jochen Theodorou 
> wrote:
>
>>
>>
>> Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
>> > I mean that Java.next’s syntax for raw strings does not support
>> variable
>> > interpolation. My understanding is that groovy won't either.
>>
>> we have actually 4 multiline string variants, of which 1 is not
>> supporting variable interpolation
>> http://groovy-lang.org/syntax.html#_string_summary_table
>>
>> What the Java version does and we not, is having no interpolation for
>> escapes. We have the dollar-slashy-string to have a different escape
>> symbol, but without escapes (raw strings) is nothing we have.
>>
>> And actually I don't think we need raw string literals in Groovy at
>> all... but that might be because I do not see good use for them beyond
>> regular expressions, and for those we have a solution in Groovy already.
>>
>> bye Jochen
>>
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

I also thought we already agreed on that. I do get where Jochen is coming from, 
however not supporting this less mainstream but certainly useful in certain 
scenarios Java syntax will imho not help with the problem that Groovy supports 
a large number of different (G)String literals with a non-unified syntax.
 Ursprüngliche Nachricht Von: Paul King  
Datum: 11.09.18  16:05  (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: 
[Proposal] GString is implemented eager and treated as normal String since 
groovy 3.0.0 

IIUC, raw strings don't escape unicode as well as not supporting interpolation 
or backslash escaping.I think we'll inevitably need to look at supporting it.
On Tue, Sep 11, 2018 at 9:16 PM Jochen Theodorou  wrote:




Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:

> I mean that Java.next’s syntax for raw strings does not support variable 

> interpolation. My understanding is that groovy won't either.



we have actually 4 multiline string variants, of which 1 is not 

supporting variable interpolation 

http://groovy-lang.org/syntax.html#_string_summary_table



What the Java version does and we not, is having no interpolation for 

escapes. We have the dollar-slashy-string to have a different escape 

symbol, but without escapes (raw strings) is nothing we have.



And actually I don't think we need raw string literals in Groovy at 

all... but that might be because I do not see good use for them beyond 

regular expressions, and for those we have a solution in Groovy already.



bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paul King]

IIUC, raw strings don't escape unicode as well as not supporting
interpolation or backslash escaping.
I think we'll inevitably need to look at supporting it.

On Tue, Sep 11, 2018 at 9:16 PM Jochen Theodorou  wrote:

>
>
> Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
> > I mean that Java.next’s syntax for raw strings does not support variable
> > interpolation. My understanding is that groovy won't either.
>
> we have actually 4 multiline string variants, of which 1 is not
> supporting variable interpolation
> http://groovy-lang.org/syntax.html#_string_summary_table
>
> What the Java version does and we not, is having no interpolation for
> escapes. We have the dollar-slashy-string to have a different escape
> symbol, but without escapes (raw strings) is nothing we have.
>
> And actually I don't think we need raw string literals in Groovy at
> all... but that might be because I do not see good use for them beyond
> regular expressions, and for those we have a solution in Groovy already.
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I fear this thread is going off topic, however the groovy support for raw
strings was already discussed in another thread some weeks ago.

http://groovy.329449.n5.nabble.com/About-raw-string-and-enhanced-try-with-resource-td5750413.html


Cheers, p


p

On Tue, Sep 11, 2018 at 1:16 PM Jochen Theodorou  wrote:

>
>
> Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
> > I mean that Java.next’s syntax for raw strings does not support variable
> > interpolation. My understanding is that groovy won't either.
>
> we have actually 4 multiline string variants, of which 1 is not
> supporting variable interpolation
> http://groovy-lang.org/syntax.html#_string_summary_table
>
> What the Java version does and we not, is having no interpolation for
> escapes. We have the dollar-slashy-string to have a different escape
> symbol, but without escapes (raw strings) is nothing we have.
>
> And actually I don't think we need raw string literals in Groovy at
> all... but that might be because I do not see good use for them beyond
> regular expressions, and for those we have a solution in Groovy already.
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
I mean that Java.next’s syntax for raw strings does not support variable 
interpolation. My understanding is that groovy won't either.


we have actually 4 multiline string variants, of which 1 is not 
supporting variable interpolation 
http://groovy-lang.org/syntax.html#_string_summary_table


What the Java version does and we not, is having no interpolation for 
escapes. We have the dollar-slashy-string to have a different escape 
symbol, but without escapes (raw strings) is nothing we have.


And actually I don't think we need raw string literals in Groovy at 
all... but that might be because I do not see good use for them beyond 
regular expressions, and for those we have a solution in Groovy already.


bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I mean that Java.next’s syntax for raw strings does not support variable
interpolation. My understanding is that groovy won't either.


p



On Tue, Sep 11, 2018 at 12:08 PM Andres Almiray  wrote:

> You mean Java.next’s syntax for raw strings as Groovy already has two
> versions.
>
> Sent from my primitive Tricorder
>
> On 11 Sep 2018, at 11:57, Paolo Di Tommaso 
> wrote:
>
> Raw strings would be a great addition to groovy, but as the name implies
> there shouldn't be any string interpolation with them.
>
>
> p
>
> 
>>
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Andres Almiray]

You mean Java.next’s syntax for raw strings as Groovy already has two versions. 

Sent from my primitive Tricorder

> On 11 Sep 2018, at 11:57, Paolo Di Tommaso  wrote:
> 
> Raw strings would be a great addition to groovy, but as the name implies 
> there shouldn't be any string interpolation with them. 
> 
> 
> p
> 
>> On Tue, Sep 11, 2018 at 11:49 AM Guillaume Laforge  
>> wrote:
>> Yeah, I know.
>> It was more of a joke than a serious suggestion.
>> And indeed, it would make things even more confusing.
>> 
>>> On Tue, Sep 11, 2018 at 11:46 AM Andres Almiray  wrote:
>>> Backquoted strings may become multiline strings in Java.next, akin to our 
>>> triple single-quote strings.
>>> Using ` at this time before Java.next releases multiline support would be a 
>>> problem for sure.
>>> 
>>> Cheers,
>>> Andres
>>> 
>>> ---
>>> Java Champion; Groovy Enthusiast
>>> JCP EC Associate Seat
>>> http://andresalmiray.com
>>> http://www.linkedin.com/in/aalmiray
>>> --
>>> What goes up, must come down. Ask any system administrator.
>>> There are 10 types of people in the world: Those who understand binary, and 
>>> those who don't.
>>> To understand recursion, we must first understand recursion.
>>> 
 On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge  
 wrote:
 Javascript's  `backquoted ${str}` are immutable.
 So changing the embedded variable str won't change the value of the 
 templated string.
 As if we didn't have enough variants of strings ;-) perhaps we should 
 support that one too :-)
 
> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou  
> wrote:
> 
> 
> Am 11.09.2018 um 01:59 schrieb MG:
> > Hi Jochen,
> > 
> > could you be more precise about where you see the problem(s) in your 
> > example:
> > 
> > 1) That Wrapper is not an immutable class, and you can therefore change 
> > its state after creation ?
> > 2) That GString $-expressions (outside of "${-> ...}") do not capture 
> > the expression, but the result of evaluating the expression (which 
> > oftentimes will be an Object referece) ?
> > 3) That GString is not immediately evaluated to its String 
> > representation ?
> > 4) ... ?
> 
> The problem is user expectations. Many do not expect GString to be 
> mutable, since they do not use it as a templating solution or something 
> compareable. I think we should offer something here. That does not have 
> to be GString in syntax at all.
> 
> Or we align more with Javascript tempalating and make GString immutable.
> 
> bye Jochen
 
 
 -- 
 Guillaume Laforge
 Apache Groovy committer & PMC Vice-President
 Developer Advocate @ Google Cloud Platform
 
 Blog: http://glaforge.appspot.com/
 Twitter: @glaforge
>>> 
>> 
>> 
>> -- 
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>> 
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

Raw strings would be a great addition to groovy, but as the name implies
there shouldn't be any string interpolation with them.


p

On Tue, Sep 11, 2018 at 11:49 AM Guillaume Laforge 
wrote:

> Yeah, I know.
> It was more of a joke than a serious suggestion.
> And indeed, it would make things even more confusing.
>
> On Tue, Sep 11, 2018 at 11:46 AM Andres Almiray 
> wrote:
>
>> Backquoted strings may become multiline strings in Java.next, akin to our
>> triple single-quote strings.
>> Using ` at this time before Java.next releases multiline support would be
>> a problem for sure.
>>
>> Cheers,
>> Andres
>>
>> ---
>> Java Champion; Groovy Enthusiast
>> JCP EC Associate Seat
>> http://andresalmiray.com
>> http://www.linkedin.com/in/aalmiray
>> --
>> What goes up, must come down. Ask any system administrator.
>> There are 10 types of people in the world: Those who understand binary,
>> and those who don't.
>> To understand recursion, we must first understand recursion.
>>
>> On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge 
>> wrote:
>>
>>> Javascript's  `backquoted ${str}` are immutable.
>>> So changing the embedded variable str won't change the value of the
>>> templated string.
>>> As if we didn't have enough variants of strings ;-) perhaps we should
>>> support that one too :-)
>>>
>>> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou 
>>> wrote:
>>>


 Am 11.09.2018 um 01:59 schrieb MG:
 > Hi Jochen,
 >
 > could you be more precise about where you see the problem(s) in your
 > example:
 >
 > 1) That Wrapper is not an immutable class, and you can therefore
 change
 > its state after creation ?
 > 2) That GString $-expressions (outside of "${-> ...}") do not capture
 > the expression, but the result of evaluating the expression (which
 > oftentimes will be an Object referece) ?
 > 3) That GString is not immediately evaluated to its String
 representation ?
 > 4) ... ?

 The problem is user expectations. Many do not expect GString to be
 mutable, since they do not use it as a templating solution or something
 compareable. I think we should offer something here. That does not have
 to be GString in syntax at all.

 Or we align more with Javascript tempalating and make GString immutable.

 bye Jochen

>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Twitter: @glaforge 
>>>
>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Guillaume Laforge]

Yeah, I know.
It was more of a joke than a serious suggestion.
And indeed, it would make things even more confusing.

On Tue, Sep 11, 2018 at 11:46 AM Andres Almiray  wrote:

> Backquoted strings may become multiline strings in Java.next, akin to our
> triple single-quote strings.
> Using ` at this time before Java.next releases multiline support would be
> a problem for sure.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
> On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge 
> wrote:
>
>> Javascript's  `backquoted ${str}` are immutable.
>> So changing the embedded variable str won't change the value of the
>> templated string.
>> As if we didn't have enough variants of strings ;-) perhaps we should
>> support that one too :-)
>>
>> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou 
>> wrote:
>>
>>>
>>>
>>> Am 11.09.2018 um 01:59 schrieb MG:
>>> > Hi Jochen,
>>> >
>>> > could you be more precise about where you see the problem(s) in your
>>> > example:
>>> >
>>> > 1) That Wrapper is not an immutable class, and you can therefore
>>> change
>>> > its state after creation ?
>>> > 2) That GString $-expressions (outside of "${-> ...}") do not capture
>>> > the expression, but the result of evaluating the expression (which
>>> > oftentimes will be an Object referece) ?
>>> > 3) That GString is not immediately evaluated to its String
>>> representation ?
>>> > 4) ... ?
>>>
>>> The problem is user expectations. Many do not expect GString to be
>>> mutable, since they do not use it as a templating solution or something
>>> compareable. I think we should offer something here. That does not have
>>> to be GString in syntax at all.
>>>
>>> Or we align more with Javascript tempalating and make GString immutable.
>>>
>>> bye Jochen
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>
>

-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paul King]

Raw strings might already be in the 12 pre-releases. We can perhaps try
them out. :-)

Cheers, Paul.

On Tue, Sep 11, 2018 at 7:46 PM Andres Almiray  wrote:

> Backquoted strings may become multiline strings in Java.next, akin to our
> triple single-quote strings.
> Using ` at this time before Java.next releases multiline support would be
> a problem for sure.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
> On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge 
> wrote:
>
>> Javascript's  `backquoted ${str}` are immutable.
>> So changing the embedded variable str won't change the value of the
>> templated string.
>> As if we didn't have enough variants of strings ;-) perhaps we should
>> support that one too :-)
>>
>> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou 
>> wrote:
>>
>>>
>>>
>>> Am 11.09.2018 um 01:59 schrieb MG:
>>> > Hi Jochen,
>>> >
>>> > could you be more precise about where you see the problem(s) in your
>>> > example:
>>> >
>>> > 1) That Wrapper is not an immutable class, and you can therefore
>>> change
>>> > its state after creation ?
>>> > 2) That GString $-expressions (outside of "${-> ...}") do not capture
>>> > the expression, but the result of evaluating the expression (which
>>> > oftentimes will be an Object referece) ?
>>> > 3) That GString is not immediately evaluated to its String
>>> representation ?
>>> > 4) ... ?
>>>
>>> The problem is user expectations. Many do not expect GString to be
>>> mutable, since they do not use it as a templating solution or something
>>> compareable. I think we should offer something here. That does not have
>>> to be GString in syntax at all.
>>>
>>> Or we align more with Javascript tempalating and make GString immutable.
>>>
>>> bye Jochen
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Andres Almiray]

Backquoted strings may become multiline strings in Java.next, akin to our
triple single-quote strings.
Using ` at this time before Java.next releases multiline support would be a
problem for sure.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Tue, Sep 11, 2018 at 11:31 AM, Guillaume Laforge 
wrote:

> Javascript's  `backquoted ${str}` are immutable.
> So changing the embedded variable str won't change the value of the
> templated string.
> As if we didn't have enough variants of strings ;-) perhaps we should
> support that one too :-)
>
> On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou 
> wrote:
>
>>
>>
>> Am 11.09.2018 um 01:59 schrieb MG:
>> > Hi Jochen,
>> >
>> > could you be more precise about where you see the problem(s) in your
>> > example:
>> >
>> > 1) That Wrapper is not an immutable class, and you can therefore change
>> > its state after creation ?
>> > 2) That GString $-expressions (outside of "${-> ...}") do not capture
>> > the expression, but the result of evaluating the expression (which
>> > oftentimes will be an Object referece) ?
>> > 3) That GString is not immediately evaluated to its String
>> representation ?
>> > 4) ... ?
>>
>> The problem is user expectations. Many do not expect GString to be
>> mutable, since they do not use it as a templating solution or something
>> compareable. I think we should offer something here. That does not have
>> to be GString in syntax at all.
>>
>> Or we align more with Javascript tempalating and make GString immutable.
>>
>> bye Jochen
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Mikko Värri]

> On 11 Sep 2018, at 12.31, Guillaume Laforge  wrote:
> 
> Javascript's  `backquoted ${str}` are immutable.
> So changing the embedded variable str won't change the value of the templated 
> string.
> As if we didn't have enough variants of strings ;-) perhaps we should support 
> that one too :-)
> 


Except that backquotes might have a different purpose on Java later :D

http://openjdk.java.net/jeps/326

-mikko

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Guillaume Laforge]

Javascript's  `backquoted ${str}` are immutable.
So changing the embedded variable str won't change the value of the
templated string.
As if we didn't have enough variants of strings ;-) perhaps we should
support that one too :-)

On Tue, Sep 11, 2018 at 11:20 AM Jochen Theodorou  wrote:

>
>
> Am 11.09.2018 um 01:59 schrieb MG:
> > Hi Jochen,
> >
> > could you be more precise about where you see the problem(s) in your
> > example:
> >
> > 1) That Wrapper is not an immutable class, and you can therefore change
> > its state after creation ?
> > 2) That GString $-expressions (outside of "${-> ...}") do not capture
> > the expression, but the result of evaluating the expression (which
> > oftentimes will be an Object referece) ?
> > 3) That GString is not immediately evaluated to its String
> representation ?
> > 4) ... ?
>
> The problem is user expectations. Many do not expect GString to be
> mutable, since they do not use it as a templating solution or something
> compareable. I think we should offer something here. That does not have
> to be GString in syntax at all.
>
> Or we align more with Javascript tempalating and make GString immutable.
>
> bye Jochen
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

Am 11.09.2018 um 01:59 schrieb MG:

Hi Jochen,

could you be more precise about where you see the problem(s) in your 
example:


1) That Wrapper is not an immutable class, and you can therefore change 
its state after creation ?
2) That GString $-expressions (outside of "${-> ...}") do not capture 
the expression, but the result of evaluating the expression (which 
oftentimes will be an Object referece) ?

3) That GString is not immediately evaluated to its String representation ?
4) ... ?


The problem is user expectations. Many do not expect GString to be 
mutable, since they do not use it as a templating solution or something 
compareable. I think we should offer something here. That does not have 
to be GString in syntax at all.


Or we align more with Javascript tempalating and make GString immutable.

bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

Hi Jochen,

could you be more precise about where you see the problem(s) in your 
example:


1) That Wrapper is not an immutable class, and you can therefore change 
its state after creation ?
2) That GString $-expressions (outside of "${-> ...}") do not capture 
the expression, but the result of evaluating the expression (which 
oftentimes will be an Object referece) ?

3) That GString is not immediately evaluated to its String representation ?
4) ... ?

And what you would accordingly want to see improved and how ?

Cheers,
mg


On 10.09.2018 20:33, Jochen Theodorou wrote:

On 10.09.2018 18:51, Alessio Stalla wrote:
Yes, but a toString method with side effects is a really bad coding 
practice that won't be fixed simply by reducing the power of GString. 


well...


class Wrapper {
  def x
  String toString(){x}
}

def w = new Wrapper(x:1)
def gstring = "$w"
assert gstring == "1"
w.x = 2
assert gstring == "2"
w = new Wrapper(x:3)
assert gstring == "2" 


I don't think that example really falls under your really bad coding. 
You have this problem with lists and maps all the time


bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

But this is not necessarily a problem. It's how mutable objects work.
GString is mutable, transitively. If you want to convert it into an
immutable type, you can already - by calling toString on the GString.

Daniel's example and rationale are about side effects inside the toString
method itself. Which /is/ really poor practice.


On Mon, Sep 10, 2018, 20:33 Jochen Theodorou  wrote:

> On 10.09.2018 18:51, Alessio Stalla wrote:
> > Yes, but a toString method with side effects is a really bad coding
> > practice that won't be fixed simply by reducing the power of GString.
>
> well...
>
> > class Wrapper {
> >   def x
> >   String toString(){x}
> > }
> >
> > def w = new Wrapper(x:1)
> > def gstring = "$w"
> > assert gstring == "1"
> > w.x = 2
> > assert gstring == "2"
> > w = new Wrapper(x:3)
> > assert gstring == "2"
>
> I don't think that example really falls under your really bad coding.
> You have this problem with lists and maps all the time
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Jochen Theodorou]

On 10.09.2018 18:51, Alessio Stalla wrote:
Yes, but a toString method with side effects is a really bad coding 
practice that won't be fixed simply by reducing the power of GString. 


well...


class Wrapper {
  def x
  String toString(){x}
}

def w = new Wrapper(x:1)
def gstring = "$w"
assert gstring == "1"
w.x = 2
assert gstring == "2"
w = new Wrapper(x:3)
assert gstring == "2" 


I don't think that example really falls under your really bad coding. 
You have this problem with lists and maps all the time


bye Jochen

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

Yes, but a toString method with side effects is a really bad coding
practice that won't be fixed simply by reducing the power of GString. Far
from it. Actually it will manifest in even worse ways. GString merely makes
it visible.
Rather, a compiler warning or IDE warning about side effects in methods
inherited from Object and overriden is a nice, non invasive way of dealing
with the same problem.


On Mon, 10 Sep 2018 at 14:27, Daniel.Sun  wrote:

> What I want to refine is the confusing GString feature shown by the first
> example(toString method with side effects)
>
> P.S.  I never propose to make most of users' code not work and angry.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

What I want to refine is the confusing GString feature shown by the first
example(toString method with side effects)

P.S.  I never propose to make most of users' code not work and angry.

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

But are users confused by GString today? Or would they be confused if its
behaviour changed and their code stopped working? Also, which users do you
have in mind, noobies, experts, DSL writers, ...?

I for one would like GString to stay the way it is. The examples you
presented don't show problems with GString, rather they show how other
issues can manifest through GString.

The first example is a toString method with side effects, which is
definitely poor practice. If you wanted to showcase in general the
interaction of mutable objects with GString, then the current behavior
(GString reflects the object's state) might actually be what users want.
I.e. GString as a crude but effective template solution.

The second example is a problem with type inference. Accessing a
Map by a key which is not a String should raise a warning. Also
if it's not already the case the static compiler could handle String x =
"$k" by silently inserting a toString() call, i.e., emitting an implicit
type conversion.


On Sun, 9 Sep 2018 at 07:10, Daniel.Sun  wrote:

> Hi MG,
>
>   The original target of the proposal is to make GString not confuse
> users and make GString behave same both in dynamic and static compilation
> mode. so it will only introduces breaking changes just in some edge cases.
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

Hi Daniel,
ok, will wait & comment on detailed proposal(s) then :-)
Cheers,mg

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 09.09.18  07:10  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: [Proposal] GString is implemented eager and treated as normal
   String since groovy 3.0.0 
Hi MG,

  The original target of the proposal is to make GString not confuse
users and make GString behave same both in dynamic and static compilation
mode. so it will only introduces breaking changes just in some edge cases.

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

Hi Daniel,
ok, will wait & comment on detailed proposal(s) then :-)
Cheers,mg

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 09.09.18  07:10  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: [Proposal] GString is implemented eager and treated as normal
   String since groovy 3.0.0 
Hi MG,

  The original target of the proposal is to make GString not confuse
users and make GString behave same both in dynamic and static compilation
mode. so it will only introduces breaking changes just in some edge cases.

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

Hi MG,

  The original target of the proposal is to make GString not confuse
users and make GString behave same both in dynamic and static compilation
mode. so it will only introduces breaking changes just in some edge cases.

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

Hi Daniel,
I am (as you probably noticed) with you on the "Groovy 3.0 is the time to 
reevaluate some things in Groovy". 
Right now I am just not sure if any change in GString semantics would not break 
my framework, since I not only need to be able to access the GString embedded 
objects, but also output the current GString state convertd toString() for 
debug purposes...
Maybe what you propose could be gotten with an extended GString literal syntax, 
eg an "S"-prefix:
String s = S"x=$x" // equivalent to "x=$x".toString()
or simply a
String getS() { toString() }
property in GString class:
String s = "x=$x".s
?
Cheers,mg

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 09.09.18  00:29  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: [Proposal] GString is implemented eager and treated as normal
  String since groovy 3.0.0 
Hi MG,

  No worries. This is just a proposal for the eager case of GString. We
will discuss further. According to the sample you provided, we should still
expose GString API.

  P.S.  Since groovy 3 will contain some breaking changes( mostly for
edge cases), it's an opportunity to refine existing implementation of
GString. 

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[mg]

Hi Daniel,
I am (as you probably noticed) with you on the "Groovy 3.0 is the time to 
reevaluate some things in Groovy". 
Right now I am just not sure if any change in GString semantics would not break 
my framework, since I not only need to be able to access the GString embedded 
objects, but also output the current GString state convertd toString() for 
debug purposes...
Maybe what you propose could be gotten with an extended GString literal syntax, 
eg an "S"-prefix:
String s = S"x=$x" // equivalent to "x=$x".toString()
or simply a
String getS() { toString() }
property in GString class:
String s = "x=$x".s
?
Cheers,mg

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 09.09.18  00:29  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: [Proposal] GString is implemented eager and treated as normal
  String since groovy 3.0.0 
Hi MG,

  No worries. This is just a proposal for the eager case of GString. We
will discuss further. According to the sample you provided, we should still
expose GString API.

  P.S.  Since groovy 3 will contain some breaking changes( mostly for
edge cases), it's an opportunity to refine existing implementation of
GString. 

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

Hi MG,

  No worries. This is just a proposal for the eager case of GString. We
will discuss further. According to the sample you provided, we should still
expose GString API.

  P.S.  Since groovy 3 will contain some breaking changes( mostly for
edge cases), it's an opportunity to refine existing implementation of
GString. 

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[MG]

Hi Daniel,

another flag from me: If I understand you correctly, you want to change 
existing GString literal semantics to make it work as if toString() had 
implicitely on it; i.e. there would be no more GString literal, but 
instead String interpolation support for regular String literals in 
double quotes ?


This would be a framework breaking change for me, since I am using the 
GString feature to be able to access a GString's embedded objects 
extensively in my SQL building framework.


Simple example:

String category = "HEAD"

final Table pe = Table.reference(PERSON)
final Table org = Table.reference(ORG_TREE)

GString sql = """
    select $pe.ID, $pe.FIRST_NAME, $pe.LAST_NAME, $org.DEPARTMENT
    from $pe, $org
    where
    $pe.ORG_ID = $org.ID and $org.CATEGORY = ${BindValue.val(category)}
"""

sql = tableToViewSubstitution(sql) // Replace some table instances with 
their View equivalent


sql = renumberReferenceNames(sql) // Iterates over sql.objects, 
modifying embedded Table/Column/View/... objects from my framework


SqlExecutor.create(...).rows(sql) // Convert passed sql GString into 
Groovy Sql compatible GString


How is the proposed change expected to work with existing Groovy Sql 
support for implicitly interpreting embedded objects as bind values 
(since this is too restrictive/inflexible for heavy use I have changed 
this from implicit to explicit support (BindValue class) in my framework).


Cheers,
mg


On 08.09.2018 03:07, Daniel.Sun wrote:

Hi all,

   In most of cases, we just use GString as an enhanced String, but
currently GString is not implemented eager so it has some weird features,
which will confuse users. Let's look at some examples[1] from Jochen:

* the referenced variables are bound eager
* toString on GString evaluates the GString, this includes toString for the
values
```
def x = 1
def gstring = "$x"
assert gstring == "1"
x = 2
assert gstring == "1"
```
```
class X {
   int i = 0
   String toString(){Integer.toString(i++)}
}
def x = new X()
def gstring = "$x"
assert gstring == "0"
assert gstring == "1" // the content of gstring changed...
```

   If we implement GString eager and treated as normal String(not expose
GString API), the content of GString will not change once it is evaluated.
We can get the following benefits:
1)  Users will not be confused because of some weird feature;
2)  Better compatibility between dynamic and static compilation, SEE
GROOVY-6668[1];
3)  The performance will be improved to some extent because GString will not
be evaluated again and again even if its content is not changed;

  The proposal is a breaking change, so I propose it is targeted to
groovy 3.0.0 if accepted.

P.S. some issues like GROOVY-6668 are raised by users again and again, that
is say, many users are confused by current implementation, i.e. GString can
not be treated as normal String in STC. In the static compilation mode:
```
@groovy.transform.CompileStatic
class Test {
 static void main(String[] args) {
 def m = ['a':1, 'b':2]
 def k = 'a'
 assert 1 == m[k]
 assert 1 == m["$k" as String]
 assert 1 == m["$k"] // fails, gets null, which is not equal to 1
 }
}

```


Cheers,
Daniel.Sun

[1] https://github.com/apache/groovy/pull/708





-
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paul King]

I agree that the two cases you provide shouldn't change. I believe what
Daniel is describing
might best be considered as an optimisation for the eager case. Rather than
having a GString
object with an array of "constant" Strings and an array of "constant"
Values, when this case is
determined, it could instead be replaced by a String. You would lose the
ability to modify
the GString after creation, e.g. in your example, eagerGString.values[0] =
3.

On Sat, Sep 8, 2018 at 9:26 PM Paolo Di Tommaso 
wrote:

> I would like to raise a flag here.
>
> Stated the Groovy documentation a Gstring can be resolved both in a eager
> and lazy manner:
>
> def number = 1 def eagerGString = "value == ${number}"def lazyGString = 
> "value == ${ -> number }"
> assert eagerGString == "value == 1" assert lazyGString ==  "value == 1"
>
> number = 2 assert eagerGString ==  "value == 1"assert lazyGString == "value 
> == 2"
>
>
>
>
> http://groovy-lang.org/syntax.html#_special_case_of_interpolating_closure_expressions
>
> The example you are reporting should *already* be reasolved eagerly and I
> can agree that it can be confusing.
>
> However the ability to resolve a GString lazily it's a very important
> Groovy feature for DSL builders. Wipe it out would have a serious impact
> (read destroy) on existing frameworks that rely on that feature.
>
>
> Cheers,
> Paolo
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paolo Di Tommaso]

I would like to raise a flag here.

Stated the Groovy documentation a Gstring can be resolved both in a eager
and lazy manner:

def number = 1 def eagerGString = "value == ${number}"def lazyGString
= "value == ${ -> number }"
assert eagerGString == "value == 1" assert lazyGString ==  "value == 1"

number = 2 assert eagerGString ==  "value == 1"assert lazyGString ==
"value == 2"



http://groovy-lang.org/syntax.html#_special_case_of_interpolating_closure_expressions

The example you are reporting should *already* be reasolved eagerly and I
can agree that it can be confusing.

However the ability to resolve a GString lazily it's a very important
Groovy feature for DSL builders. Wipe it out would have a serious impact
(read destroy) on existing frameworks that rely on that feature.


Cheers,
Paolo

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Daniel.Sun]

Hi Paul,

That would be great to get your help :-)

As we decided to make groovy 3 not completely compatible with previous
versions in the past discussions, I think it's good to think about how to
refine the implementation of `GString` too.

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Paul King]

I think a GEP would be the right thing for a change like this. I'd be
willing to help try to put it together.
I'd hope we could come up with an approach which allows eager or lazy.
I don't want to get hung up on syntax but perhaps "${x}" could be eager and
"${ -> x }"
could be the current semantics or some alternative to this.

But anyway, a GEP could outline the exact proposed change across dynamic
and static Groovy with pros and cons etc.

Cheers, Paul.


On Sat, Sep 8, 2018 at 11:07 AM Daniel.Sun  wrote:

> Hi all,
>
>   In most of cases, we just use GString as an enhanced String, but
> currently GString is not implemented eager so it has some weird features,
> which will confuse users. Let's look at some examples[1] from Jochen:
>
> * the referenced variables are bound eager
> * toString on GString evaluates the GString, this includes toString for the
> values
> ```
> def x = 1
> def gstring = "$x"
> assert gstring == "1"
> x = 2
> assert gstring == "1"
> ```
> ```
> class X {
>   int i = 0
>   String toString(){Integer.toString(i++)}
> }
> def x = new X()
> def gstring = "$x"
> assert gstring == "0"
> assert gstring == "1" // the content of gstring changed...
> ```
>
>   If we implement GString eager and treated as normal String(not expose
> GString API), the content of GString will not change once it is evaluated.
> We can get the following benefits:
> 1)  Users will not be confused because of some weird feature;
> 2)  Better compatibility between dynamic and static compilation, SEE
> GROOVY-6668[1];
> 3)  The performance will be improved to some extent because GString will
> not
> be evaluated again and again even if its content is not changed;
>
>  The proposal is a breaking change, so I propose it is targeted to
> groovy 3.0.0 if accepted.
>
> P.S. some issues like GROOVY-6668 are raised by users again and again, that
> is say, many users are confused by current implementation, i.e. GString can
> not be treated as normal String in STC. In the static compilation mode:
> ```
> @groovy.transform.CompileStatic
> class Test {
> static void main(String[] args) {
> def m = ['a':1, 'b':2]
> def k = 'a'
> assert 1 == m[k]
> assert 1 == m["$k" as String]
> assert 1 == m["$k"] // fails, gets null, which is not equal to 1
> }
> }
>
> ```
>
>
> Cheers,
> Daniel.Sun
>
> [1] https://github.com/apache/groovy/pull/708
>
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>