Multiline string literals
peter.kitt.reilly at gmail.com
Sat Aug 6 15:16:40 PDT 2011
Thanks for the update!
my google powers are pretty poor ;-)
I do not agree that """ is IDE unfriendly, at
least in the sense that is is supported by
the three main java ides (for groovy), and in theory any editor
that supports python.
Back in 2006 (yicks, is it that long ago), I hacked
the javac compiler to add support for """ multiline support,
it was ridiculously easy - see
On Sat, Aug 6, 2011 at 9:30 PM, Ruslan Shevchenko
<ruslan at shevchenko.kiev.ua> wrote:
> 1. Last submission: 1.4 for multiine string literals is
> which in many aspects differ from first version.
> Also, I maintain 'post-morten' final version:
> 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
> 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:
>> 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/
More information about the coin-dev