Proposal: Embedded Expressions for String Statements

[Stefan Schulz]

Howard mentioned it before, embedding expressions might be a nice thing 
to have in Java. The simplest thing is to embed variables to print their 
value.
The proposal is not at the same level as Multi-line Strings, as it does 
not result in a construction of a String Literal but rather offers a 
"short cut" for building complex Strings.
To at least have a basis for discussion, I set up a proposal that IMO 
could fit in the scope of COIN.

Stefan


Proposal: Embedded Expressions for String Statements

AUTHOR(S):

Stefan Schulz

VERSION:

1.0    Initial version.

Formatted version:
http://docs.google.com/Doc?id=ddhp95vd_11dv7rmrcp


OVERVIEW

FEATURE SUMMARY:

Often, textual output is constructed of a mix of plain text and values 
resolving from expressions. An escape sequence allows embedding such 
expressions into a string. If the result of the expression is no String, 
it will be converted to one.

MAJOR ADVANTAGE:

Improves readability and eases String construction.

MAJOR BENEFIT:

Reduces the cluttering in writing textual output.

MAJOR DISADVANTAGE:

May encourage to write one-liners with many expressions inside a String 
construction.

ALTERNATIVES:

Write strings the old way by using concatenations or using builders.


EXAMPLES

SIMPLE EXAMPLE:
   String name = "Dave";
   System.out.println("Hello, \{name}!");

ADVANCED EXAMPLE:
   Object product = produce();
   log("We \{product == null ? "failed" : "produced \{product}"}!");


DETAILS

SPECIFICATION:

The new escape sequence \{ will be handled at compile time by 
transforming the string statement into a concatenation of Strings. 
Neither can the statement be understood as a String literal nor is it an 
escape sequence in the sense of representing a single character literal. 
Therefore, the transformation has to be done prior to any other escape 
sequence handling.

Changes are required in the JLS §3.10.5 "String Literals" and 3.10.6 
"Escape Sequences for Character and String Literals". Although the new 
escape sequence does not form a part of a String literal, it must be 
stated that it's a legit escape sequence with the consequence of making 
the string sequence become a statement rather than a literal.

A new chapter is to be introduced on embedding expressions in string 
sequences, which closely relates to §15.18.1 "String Concatenation 
Operator +". The syntax would be as follows:

EmbeddedExpressionStatement:
   " StringCharactersAndExpression StringCharactersOpt "

StringCharactersAndExpression
   StringCharactersOpt EmbeddedExpression StringCharactersAndExpressionOpt

EmbeddedExpression
   \ { Expression }

Note: The sequence "\{exp}" is deliberately chosen as it resembles the 
way other languages provide a similar ability, e.g., JavaFX ("{exp}"), 
PHP, Python and Groovy ("${exp}").

COMPILATION:

In general, the statement will be transformed into a concatenation of 
literals and expressions. In the following, the String Concatenation 
Operator is being used, but maybe replaced by a StringBuilder solution. 
The latter might be easy to do, as the transformation happens before 
literal processing.

Transformed simple example:
   String name = "Dave";
   System.out.println("Hello, " + name + "!");

Transformed complex example:
   Object product = produceSomething();
   log("We " + (product == null ? "failed" : "produced " + product) + "!");

TESTING:

The transformation has to be tested to resolve to the expected old style 
way of concatenating Strings. The cases should cover simple variable 
references (null, primitive, String, and Object) as well as simple and 
nested expressions (including nested expressions with Strings having 
embedded expressions).

LIBRARY SUPPORT:

None.

REFLECTIVE APIS:

None.

OTHER CHANGES:

None.

MIGRATION:

Replace existing old style concatenation by applying the new escape 
sequence.


COMPATIBILITY

BREAKING CHANGES:

None. The escape sequence \{ would prior have caused a compiler error.

EXISTING PROGRAMS:

No changes.


REFERENCES

EXISTING BUGS:

(Although it is to be assumed there are existing bugs/rfes, the search 
did not pop up results for the keywords used. So this remains to be done.)

URL FOR PROTOTYPE (optional):

None of yet.