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/09 05:10:33 UTC
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>.
> 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