PROPOSAL: Multiline strings

[rssh at gradsoft.com.ua]

>
> On 8 mrt 2009, at 18:17, Stefan Schulz <schulz at e-spirit.de> wrote:
>
>> I quite liked the idea of handling newlines by adding methods to
>> String,
>> to overcome magic conversions. When reading back about indentation
>> etc.,
>> I wonder, why not to apply a similar technique to get rid of
>> indent-related white spaces.
>>

 In principle possible. But when you write multiline string,  you really
mean string with whitespace processing by default.  So, with approach of
whitespace-processing method, typical programs will contains call of
this method near any multiline string constant. So, information density of
program with such calls will be lower then information density of analogical
program without ones.

I think better changes to language must increase information density of
typical program, not decrease one.


>> Another question on multi-line Strings I have: does it make sense to
>> allow a multi-line String only having one line? If not, why not using
>> the sequence double-quote plus newline as marker for multi-line
>> Strings?

 I afraid this is question of taste. I choose """ because this is in
groovy and  scala; codebase of our organization are in java, groovy as
main development languages, also we have some experimental parts on
scala.
So, """ will mean near the same in near all languages.

 But difference between """ and "\n is not principal: one quote is also
good variant.

  Generally, I prefer to  resolve such questing by voting; from other side
 reaction on my previous voting-like messages in this list was zero ;).


>>
>> I don't think that wrong indentation inside a String should lead to a
>> compiler error, that's why methods like above would suffice IMO. All

 Agree, change to waring.

>> the
>> compiler would have to do is to automatically add (platform specific)
>> line breaks.
>>
 platform specifics line breaks principle 'Write one, run anywhere'.
I think '\n' breaks and just processing next lines without removing
indentation should be ok.


>> Stefan
>>
>
>