About raw string and enhanced try-with-resource

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About raw string and enhanced try-with-resource

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



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

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

Jochen Theodorou


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
Reply | Threaded
Open this post in threaded view
|

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

Daniel.Sun
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
Reply | Threaded
Open this post in threaded view
|

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

Jesper Steen Møller

> On 15 May 2018, at 12.14, Daniel.Sun <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Paolo Di Tommaso
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 <[hidden email]> wrote:

> On 15 May 2018, at 12.14, Daniel.Sun <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Jesper Steen Møller
On 15 May 2018, at 12.31, Paolo Di Tommaso <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Cédric Champeau
+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 <[hidden email]>:
On 15 May 2018, at 12.31, Paolo Di Tommaso <[hidden email]> 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


MG
Reply | Threaded
Open this post in threaded view
|

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

MG
In reply to this post by Jochen Theodorou


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



Reply | Threaded
Open this post in threaded view
|

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

Jochen Theodorou
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
MG
Reply | Threaded
Open this post in threaded view
|

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

MG
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


12