Multiline string literals

[Ruslan Shevchenko]

1. Last submission: 1.4 for multiine string literals is
     http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html
 which in many aspects differ from first version.

Also, I maintain 'post-morten' final version:
   https://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw
 which can be used as starting point, if Oracle decide to receive
proposals about language direction from external world with reopening
or creation of some analog  of project coin.    [my estimation for
probability of such case is not very hight.]

2.  In general, this proposal describe multiline strings as they
implemented in scala and groovy now.  One problem with this: """ are
IDE-unfriendly: complexity of implementing mulitline string support
for groovy in netbeans shows this.

So, now I think that  """"  symbols in proposal is better change to
pair of  "(    )"   (and '(    )'  for row string literals),  simular
to brackets for multiline string literals in C++0x
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm

Regards !

On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner <per at bothner.com> wrote:
> On 08/06/2011 03:41 AM, Peter Reilly wrote:
>> Now that jdk7 is released and there will shortly be a process for
>> asking for new small features in jdk8, I would like to ask that
>> support for multiline string literals be considered.
>>
>> This is a long standing request and a specific proposal is contained in:
>>
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html
>
> I think it would be a mistake for multiline string literals to have
> the ending delimiter be the same as the starting delimiter.  It seems
> lie it would make things more difficult for IDEs.  Using """ also seems
> prone to syntax errors with possibly-confusing error messages.  And it makes
> it harder to scan the text (visually or with tools) for matching delimiters.
>
> I also think this is a questionable idea:
>
> String platformDepended="""q
> """;
> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows.
>
> This make the meaning of a program depend on which platform
> it is compiled on.  Probably not something we want.  You could
> change it to depend on the program it is *run* on, by defining it
> in terms of line.separator - that would make more sense.
> --
>        --Per Bothner
> per at bothner.com   http://per.bothner.com/
>
>