You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2018/09/08 01:07:25 UTC
[Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
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
Posted by "Daniel.Sun" <su...@apache.org>.
> 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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by Mikko Värri <mi...@varri.fi>.
> On 11 Sep 2018, at 12.31, Guillaume Laforge <gl...@gmail.com> 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
Posted by Guillaume Laforge <gl...@gmail.com>.
No, it's never been there, it's never been supported in Groovy.
Le mar. 11 sept. 2018 à 18:39, Jochen Theodorou <bl...@gmx.org> 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
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by Paco Zarate <co...@nazcasistemas.com>.
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 <mg...@arscreat.com> 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 <pa...@asert.com.au>
> 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 <bl...@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
Posted by mg <mg...@arscreat.com>.
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 <pa...@asert.com.au> 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 <bl...@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
Posted by Paul King <pa...@asert.com.au>.
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 <bl...@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
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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 <bl...@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
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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 <aa...@gmail.com> 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 <pa...@gmail.com>
> 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
>
> <http://twitter.com/glaforge>
>>
>
Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Posted by Andres Almiray <aa...@gmail.com>.
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 <pa...@gmail.com> 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 <gl...@gmail.com> 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 <aa...@gmail.com> 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 <gl...@gmail.com> 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 <bl...@gmx.org> 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
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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 <gl...@gmail.com>
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 <aa...@gmail.com>
> 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 <gl...@gmail.com>
>> 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 <bl...@gmx.org>
>>> 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 <http://twitter.com/glaforge>
>>>
>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge <http://twitter.com/glaforge>
>
Re: [Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <aa...@gmail.com> 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 <gl...@gmail.com>
> 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 <bl...@gmx.org>
>> 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 <http://twitter.com/glaforge>
>>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: [Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
Posted by Paul King <pa...@asert.com.au>.
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 <aa...@gmail.com> 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 <gl...@gmail.com>
> 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 <bl...@gmx.org>
>> 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 <http://twitter.com/glaforge>
>>
>
>
Re: [Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
Posted by Andres Almiray <aa...@gmail.com>.
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 <gl...@gmail.com>
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 <bl...@gmx.org>
> 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 <http://twitter.com/glaforge>
>
Re: [Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <bl...@gmx.org> 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 <http://twitter.com/glaforge>
Re: [Proposal] GString is implemented eager and treated as normal
String since groovy 3.0.0
Posted by mg <mg...@arscreat.com>.
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 <bl...@gmx.org> Datum: 11.09.18 11:20 (GMT+01:00) An: MG <mg...@arscreat.com>, 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
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by MG <mg...@arscreat.com>.
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
Posted by Alessio Stalla <al...@gmail.com>.
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 <bl...@gmx.org> 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
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by Alessio Stalla <al...@gmail.com>.
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 <su...@apache.org> 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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by Alessio Stalla <al...@gmail.com>.
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<String, ?> 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 <su...@apache.org> 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
Posted by mg <mg...@arscreat.com>.
Hi Daniel,
ok, will wait & comment on detailed proposal(s) then :-)
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: "Daniel.Sun" <su...@apache.org> Datum: 09.09.18 07:10 (GMT+01:00) An: dev@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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by mg <mg...@arscreat.com>.
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" <su...@apache.org> Datum: 09.09.18 00:29 (GMT+01:00) An: dev@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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by MG <mg...@arscreat.com>.
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
Posted by Paul King <pa...@asert.com.au>.
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 <pa...@gmail.com>
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
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by Paul King <pa...@asert.com.au>.
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 <su...@apache.org> 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
>