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/05/15 06:42:29 UTC

About raw string and enhanced try-with-resource

Hi all,

      Java11 will introduce raw string[1], there is no similar thing in
Groovy. In order to improve the compatibility with Java, I plan to add raw
string to Groovy too. 

      Since Groovy has supported try-with-resource introduced by Java7, I
plan to support the enhanced version[2].

      If you have objections, please let me know.

Cheers,
Daniel.Sun
[1] https://issues.apache.org/jira/browse/GROOVY-8564
[2] https://issues.apache.org/jira/browse/GROOVY-8586



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

Re: About raw string and enhanced try-with-resource

Posted by "Daniel.Sun" <su...@apache.org>.
Here is the PR to support the enhanced try-with-resources introduced by Java9

https://github.com/apache/groovy/pull/714

Cheers,
Daniel.Sun



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

Re: About raw string and enhanced try-with-resource

Posted by Cédric Champeau <ce...@gmail.com>.
+1 for both. In particular I like that you can choose your own delimiter in
Java 11 raw strings.

2018-05-15 12:48 GMT+02:00 Jesper Steen Møller <je...@selskabet.org>:

> On 15 May 2018, at 12.31, Paolo Di Tommaso <pa...@gmail.com>
> wrote:
>
>
> No. There's an important difference: raw strings do not escape any special
> character ie. backlashes, dollars, back-ticks, etc.
>
>
> Ah, I didn't actually realize that Groovy's current '''multiline''' style
> interpreted \ escapes. Haven't used it much, I suppose.
>
> This is very useful for DSLs when it's required to embed a piece of
> foreign code (think for example Bash) into a string. With groovy
> multi-line string you still need to escape a lot stuff, making very
> difficult for the user to handle it.
>
>
> I totally agree, I was just wrong about the semantics of the '''multiline,
> non-interpolation string'''.
>
> -Jesper
>
>

Re: About raw string and enhanced try-with-resource

Posted by Jesper Steen Møller <je...@selskabet.org>.
On 15 May 2018, at 12.31, Paolo Di Tommaso <pa...@gmail.com> wrote:
> 
> No. There's an important difference: raw strings do not escape any special character ie. backlashes, dollars, back-ticks, etc. 
> 

Ah, I didn't actually realize that Groovy's current '''multiline''' style interpreted \ escapes. Haven't used it much, I suppose.

> This is very useful for DSLs when it's required to embed a piece of foreign code (think for example Bash) into a string. With groovy multi-line string you still need to escape a lot stuff, making very difficult for the user to handle it. 

I totally agree, I was just wrong about the semantics of the '''multiline, non-interpolation string'''.

-Jesper


Re: About raw string and enhanced try-with-resource

Posted by Paolo Di Tommaso <pa...@gmail.com>.
No. There's an important difference: raw strings do not escape any special
character ie. backlashes, dollars, back-ticks, etc.

This is very useful for DSLs when it's required to embed a piece of foreign
code (think for example Bash) into a string. With groovy multi-line string
you still need to escape a lot stuff, making very difficult for the user to
handle it.


p



On Tue, May 15, 2018 at 12:21 PM, Jesper Steen Møller <je...@selskabet.org>
wrote:

>
> > On 15 May 2018, at 12.14, Daniel.Sun <su...@apache.org> wrote:
> > [..]
> >    As you said, Groovy has many string(e.g. 'xxx', "xxx", '''xxx''',
> > """xxx""", /xxx/, $/xxx/$). but they can not cover the function of raw
> > string...
> >
>
> Isn't '''tripple-single-quoted''' basically the same as the raw string
> (only with a different delimiter?)
>
> -Jesper
>
>

Re: About raw string and enhanced try-with-resource

Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 15 May 2018, at 12.14, Daniel.Sun <su...@apache.org> wrote:
> [..]
>    As you said, Groovy has many string(e.g. 'xxx', "xxx", '''xxx''',
> """xxx""", /xxx/, $/xxx/$). but they can not cover the function of raw
> string...
> 

Isn't '''tripple-single-quoted''' basically the same as the raw string (only with a different delimiter?)

-Jesper


Re: About raw string and enhanced try-with-resource

Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jochen,

    I plan to work on enhanced try-with-resources recently. As for raw
string, it is just on my TODO list :-)

    As you said, Groovy has many string(e.g. 'xxx', "xxx", '''xxx''',
"""xxx""", /xxx/, $/xxx/$). but they can not cover the function of raw
string...

Cheers,
Daniel.Sun



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

Re: About raw string and enhanced try-with-resource

Posted by MG <mg...@arscreat.com>.
On 17.05.2018 02:31, Jochen Theodorou wrote:
> So one obvious difference between our literals and the raw string is 
> the interpretation of escaping and interpolation. But if you are 
> really thinking about it... if I have /some regexp/, then does it need 
> to be interpolated? 

I use interpolated regex strings quite a lot in my framework, to create 
regex expressions from smaller building blocks, so that would be an 
unpleasant breaking change for me.

What about not trying to reduce the number of string literals, but 
creating a uniform, building block syntax for them, where you can easily 
express different escaping/interpolation needs in a compact, unified 
manner ?

 From the top of my hat, just to visualize the general idea:

final GString multilineRegularexpressionInterpolated = mri"age:(\d+)
phone:${telephoneNumberRegex}
"

Translation
=========
'a' as Char -> c"a"  // character
'abc' -> s"abc"  // String
'''abc''' -> cm"abc" // character, multiline
"abc" -> "abc" or i"abc" // interpolated
"""abc""" -> m"abc" // multiline
/abc/ -> r"abc"  // regular
`abc` -> l"abc" // literal

// trimmed
"""
abc
""".trim()
->
t"
abc
"

// undent
undent"""
         abc
     def
""")
->
u"""
         abc
     def
"""


For more complex cases maybe use an annotation-like syntax:

// "\n" appears as the char sequence {\,n} in the resulting string
// strings given as arguments to @S(...) are always literal
final GString 
multilineRegularexpressionInterpolatedWithSpecificCharsInterpretedLiteral 
=  @S("ri",["\n"])"age:(\d+)phone:${telephoneNumberRegex}\n\n\n"

Cheers,
mg



Re: About raw string and enhanced try-with-resource

Posted by Jochen Theodorou <bl...@gmx.org>.
On 16.05.2018 23:20, MG wrote:
> 
> 
> On 15.05.2018 10:42, Jochen Theodorou wrote:
> 
>> <zip>I think we really have a big problem with our strings... we have 
>> much too many ways to express them and I think we really have to slim 
>> down here.
>>
> 
> I agree with that - any concrete ideas on what syntax you imagine ? 
> Additional "parameters"/"tag chars" after or before the opening string 
> delimiter... ?

step 1 is to make a list of our string types and define what they are 
for. As well as how much is covered by others. Then we can think of what 
we really need.

Example... let`s say we would want to add tagged templates from 
JavaScript 
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)... 
what if we use GStrings instead? What is then still missing from the 
perspective of an IDE for example to make this work. My feeling here is 
for example, that it will not require a syntax change, more a convention 
for the IDEs to ease the recognition of what is inside the string (html, 
sql, json, urls...)

So one obvious difference between our literals and the raw string is the 
interpretation of escaping and interpolation. But if you are really 
thinking about it... if I have /some regexp/, then does it need to be 
interpolated? And considering we then have raw string literals, do we 
need /some regexp/ at all? And then you have to think similar about $/.

Or actually... why do we not make '' and "" multiline? If they are, do 
we really need the tripple variant anymore?

I am not saying they do not have their justification, I just would like 
to have a re-justification of their existence. If we do not find that, 
then we should think about slowly (!) deprecating that syntax.

bye Jochen

Re: About raw string and enhanced try-with-resource

Posted by MG <mg...@arscreat.com>.

On 15.05.2018 10:42, Jochen Theodorou wrote:

> <zip>I think we really have a big problem with our strings... we have 
> much too many ways to express them and I think we really have to slim 
> down here.
>

I agree with that - any concrete ideas on what syntax you imagine ? 
Additional "parameters"/"tag chars" after or before the opening string 
delimiter... ?




Re: About raw string and enhanced try-with-resource

Posted by Jochen Theodorou <bl...@gmx.org>.

Am 15.05.2018 um 08:42 schrieb Daniel.Sun:
> Hi all,
> 
>        Java11 will introduce raw string[1], there is no similar thing in
> Groovy. In order to improve the compatibility with Java, I plan to add raw
> string to Groovy too.
> 
>        Since Groovy has supported try-with-resource introduced by Java7, I
> plan to support the enhanced version[2].
> 
>        If you have objections, please let me know.
> 
> Cheers,
> Daniel.Sun
> [1] https://issues.apache.org/jira/browse/GROOVY-8564
> [2] https://issues.apache.org/jira/browse/GROOVY-8586


+1 on try-with-resource, 0 on the raw string... is the proposal now 
fixed? Can't say I like the proposal a lot and I think we really have a 
big problem with our strings... we have much too many ways to express 
them and I think we really have to slim down here.

bye Jochen