Re: [groovy-dev] Re: [groovy-user] triple slashy string user feedback
Paul King <paulk@...
2008-04-01 11:40:04 GMT
OK, I updated the proposal page to reflect the current
state of the discussion:
Paul King wrote:
> Jochen Theodorou wrote:
>> The uses cases our current strings are not able to met are embedding
>> of groovy programs in a string without escaping and multiline regexpr.
>> And for the first I must say that I the programs may become a problem
>> when I have to use strings in them and when I copy&paste the program
>> from somewhere else. But as our eval is not as powerful as a Ruby eval
>> these embedded programs have less abilities and as such are less
>> useful. As a consequence ''' and """ do satisfy 90% of the needs here
>> already. The multiline regexpr seems to be the only reason for me to
>> add yet another heredoc string. And so I think the proposal should
>> target this as its primary goal.
> I believe if this is catered for, we will cover the embedded snippets
>> [...] Looking at the whole picture doe not mean to make each feature
> Sure, but I wanted to give others the opportunity to present
> use cases for features they believe are important.
>>> and it also leaves open the possibility of
>>> def greeting = $'hello'$
>>> which is kind of nice but perhaps not really needed.
>>> I guess the trailing $ doesn't add much, so perhaps this would do:
>>> def greeting = $"
>>> hello, $name
>> but then you have to escape ", while in the other version you
>> theoretically do not have to escape anything.
> You would need to escape it when it appears on a line by itself and
> if you follow your suggestion of allowing any characters, then we could
> have "" as the ident, e.g.:
> def greeting = $"""
> hello, $name
>> There is also another advantage and that is the usage of this kind of
>> string in expressions:
>> def greeting = $"
>> hello, $name
>> The heredoc I suggested above (not the <<(<) version) does work in
>> assignments, declarations and method calls, but you can not make it
>> part of a path expression
>>>> this way anything that follows $' can be used, not only identifiers.
>>>> I would also reduce the four variants to two, because we already
>>>> have ''' and """.
>>> That is reasonable but gives us reduced flexibility in that we couldn't
>>> do special first/last line handling and couldn't have ''' or """ in such
>> the question is if that is needed.
> For me, this is certainly in the diminishing returns category.
>>>> These two would both not support java escaping (\n is "\\n") and
>>>> would be different only in allowing GStrings or not. And then it
>>>> seems logical to do $" (with GString) and $' without.. maybe I would
>>>> use /' and /" instead to let it more look like the slashy string but
>>>> that seems not to have any value of recognition, but it is the same
>>>> for me with $' I am more used to << for here docs.... meaning <<'
>>>> and <<" or << and <<<. of course then a here doc can not be used in
>>>> a method call without parentheses, but that shouldn't be much of a
>>> I guess all of these are possible - though some look a little
>>> to me. I guess the proposals as they currently stand try to keep the
>>> current flavor of Groovy strings as much as possible rather than try
>>> to mimic PERL (or another language) implementation of here docs.
>> true, but the usage of << is very common and has a value of
>> recognition, that is very important. the $', $", $/, $< versions have
>> an optical clush with GStrings. of course they are not, but they look
>> a bit like them, especially with an identifier. Also it seems only
>> Powershell has stringsthat look a bit like that. Perl, PHP, most Unix
>> shells and Ruby do use <<. Python uses this r notation, that we can
>> not rally use, because it clashes with a method call. but again, this
>> is syntax, we need to concentrate on functionality first
> Yes, I certainly have no problem if we have only 1 or 2 here docs
> variations with using one of your suggestions. The previous choices
> were to mentally link back to single line variations to make it easy
> to remember what escaping and GString handling would be in place
> but if we are not going with all 4 variations, then another scheme
> makes sense.
>> bye blackdrag
> To unsubscribe from this list, please visit:
To unsubscribe from this list, please visit: