Proposal: Embedded Expressions for String Statements

[phil swenson]

excellent approach.  Doesn't break old code and gives me everything
I'd ever want (no escapes, embedded variables and expressions).

I vote for the back tick delimiter.

On Fri, Mar 20, 2009 at 6:03 PM, Stefan Schulz <schulz at e-spirit.de> wrote:
> In the light of the discussions on how to markup embedded expressions,
> it seems a really good idea to introduce a new form of String
> expressions (e.g. using a back-tick or triple-quotes as delimiter),
> which captures embedded expressions and "escape-free" and multiline
> Strings at the same time. For example by having ${ as new escape
> sequence introducing embedded expressions and $\ to introduce escape
> characters (where $\{ would escape from embedded expressions, $\\ from
> escape characters and, e.g., $\n would be a line break). I'm not sure
> about the $foo form, though.
> While it seems to require more characters now for escaping, the chances
> are quite high that the two sequences ${ and $\ are rare in normal text
> and the common sequences \n and \t can be replaced by using the
> multiline feature.
> It requires a bit more on pre-scanning the code, but this is only at
> compile-time when transforming the new String to old String, I think.
>
> Stefan
>
> John Rose schrieb:
>> I wrote the spec. draft and implementation (in antlr) for Groovy
>> gstring syntax; I did the work with the intention of helping the JSR
>> 241 Groovy standard.  It could work in Java with adjustments, and the
>> Groovy spec. is detailed enough to be a starting point.   I don't
>> really have time to work on it though. That's why I haven't done a
>> proposal.
>>
>> For Java, to extend the string syntax and emphasize that a new string
>> is being constructed, I recommend this:
>>
>>    new "$foo, ${bar}s."
>>
>> The new kwd enables the dollars. Other details to be taken from the
>> Groovy spec.
>>
>> Best wishes,
>>
>> -- John  (on my iPhone)
>>
>> On Mar 19, 2009, at 8:33 AM, phil swenson <phil.swenson at gmail.com>
>> wrote:
>>
>>  > funny, i just joined the list specifically to ask about this subject.
>>  >
>>  > why not just copy the groovy implementation of this?   $var or $
>>  > {expresion} ?
>>  > in groovy it would be:
>>  > "[$field1, $field2, $field3]"
>>  >
>>  > or with the explicit expression syntax:
>>  > "[${field1}, ${field2}, ${field3}]"
>>  >
>>  >
>>  > I hate escape characters :)
>>  >
>>  >
>>  > On Thu, Mar 19, 2009 at 2:03 AM, Schulz, Stefan <schulz at e-spirit.de>
>>  > wrote:
>>  >> The concat-variant to me is even worse readable than the original +-
>>  >> notation, having three consecutive commas in between.
>>  >> The proposal already mentions concatenation of any kind as
>>  >> alternative, although not mentioning concat(). Maybe worth expanding.
>>  >>
>>  >> Stefan
>>  >>
>>  >>> -----Original Message-----
>>  >>> From: rssh at gradsoft.com.ua [mailto:rssh at gradsoft.com.ua]
>>  >>> Sent: Wednesday, March 18, 2009 8:58 PM
>>  >>> To: Howard Lovatt
>>  >>> Cc: coin-dev at openjdk.java.net; Schulz, Stefan
>>  >>> Subject: Re: Proposal: Embedded Expressions for String Statements
>>  >>>
>>  >>>> I like Stefan's proposed syntax and as a way of a motivating
>>  >>>> example
>>  >>>> consider writing a toString method that gives the field
>>  >>> values within
>>  >>>> square brackets, now you would write:
>>  >>>>
>>  >>>>     "[" + field1 + ", " + field2 + ", " + field3 + "]"
>>  >>>>
>>  >>>> With the proposal you would say:
>>  >>>>
>>  >>>>     "[\{field1}, \{field2}, \{field3}]"
>>  >>>>
>>  >>>> Which I find clearer.
>>  >>>>
>>  >>>
>>  >>> Just note: now we can use much cleaner
>>  >>>  concat( field1, ',' , field2, ',' field3 )
>>  >>>
>>  >>>
>>  >>>
>>  >>>> Many thanks to Stefan for writing this up formally.
>>  >>>>
>>  >>>>
>>  >>>
>>  >>>
>>  >>>
>>  >>>
>>  >>
>>  >>
>>  >
>>
>
>