From: kangax on
On 2/3/10 1:11 AM, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
[...]
>> The two usual workarounds are
>>
>> var str = "I wish\n"
>> + "I was\n"
>> + "a multi-line string";
>
> Joining an Array of strings on newlines appears to be easier to maintain:
>
> var str = [
> "I wish",
> "I was",
> "a multi-line string"
> ].join("\n");
>
>> and
>>
>> var str = "I am the closest thing\
>> to multi-line strings that we can get\
>> with JavaScript";
>
> That is not equivalent, of course, as the leading spaces are part of the
> string value.
>
>> I don't know how well supported the second version is.
>
> I have a fair idea. My tests indicate that this feature first specified
> in ECMAScript Edition 5 is supported since JavaScript 1.8.1 (at least),
> JScript 5.1.5010, V8 1.3 (at least), JavaScriptCore 525.13 (at least),
> Opera ECMAScript 10.10 (not before), and KJS 4.3.2 (at least).

It certainly does work in Opera <10.10. At least on Mac OSX. Last time I
checked, I couldn't find a single browser that failed (for a certain
meaning of "failed") to "understand" this syntax, or result in an error;
even when testing ancient browsers like Opera 6.x, Safari 1.x, etc.

However resulting string definitely varies among implementations. In
Opera 7.54, for example:

var x = 'a\
b';

x === 'a\u000Ab'; // true

Note how there's a line feed (U+000A) in between 2 characters.

In Opera 8.01 (and later), `x` already evaluates to 'ab'.

IIRC, similar discrepancies were in other older browsers like Mac IE 5.2.

[...]

--
kangax
From: Thomas 'PointedEars' Lahn on
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Stefan Weiss wrote:
>>>> I've always wondered why multi-line string literals
>>>> aren't possible in JavaScript. AFAICS, there's nothing ambiguous about
>>>> this syntax:
>>>>
>>>> var heredoc = "I am a multi-line
>>>> string; I end when the tokenizer
>>>> sees a double quote";
>>>>
>>>> This is standard practice in many other programming languages.
>>> <snip>
>>>
>>> In C++ you would write
>>>
>>> var heredoc = "I am a multi-line "
>>> "string; I end when the tokenizer "
>>> "sees a double quote";
>> No, that is not C++ code.
>
> You time-waster.

Pot, kettle, black.

> It's perfectly valid C++ code.

No, it is not.

> var is obviously a type-name, for a type having a constructor with the
> signature
> var(const char * )

You really are pitiable.

Given the existence of preprocessor macros, almost any piece of junk can be
made to compile by a C++ compiler provided there are further definitions
and declarations. Your code *as it is*, however, is clearly not C++ code;
that is, code that compiles *as it is* (in a main() function) without
syntax error messages.

Get a life.

>> Perhaps you meant
>>
>> std::string heredoc = "I am a multi-line"
>> " string; I end when the tokenizer"
>> " sees a double quote";
>
> That's another example, but not the one I was using.

Yes, and by contrast this example compiles as it is (in a main() function).

>>> Note the double quotes at both ends of the string parts. This way, you
>>> know exactly which whitespace chars belong to the string parts and
>>> which are just there for layout.
>>
>> And by contrast it requires *special syntax*, so Stefan's assumption
>> does _not_ apply here. Thank you for the counter-example, albeit a
>> bogus one.
>
> But Stefan was suggesting additional special syntax!

No, he suggested that there are "many other programming languages" that
support simple string literals with newlines in them.

> Score adjusted.

YMMD.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Thomas 'PointedEars' Lahn on
kangax wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> [...]
>>> var str = "I am the closest thing\
>>> to multi-line strings that we can get\
>>> with JavaScript";
>>
>> That is not equivalent, of course, as the leading spaces are part of the
>> string value.
>>
>>> I don't know how well supported the second version is.
>>
>> I have a fair idea. My tests indicate that this feature first specified
>> in ECMAScript Edition 5 is supported since JavaScript 1.8.1 (at least),
>> JScript 5.1.5010, V8 1.3 (at least), JavaScriptCore 525.13 (at least),
>> Opera ECMAScript 10.10 (not before), and KJS 4.3.2 (at least).
>
> It certainly does work in Opera <10.10.

If by that you mean that it works in some versions before Opera 10.10,
then you are correct. It certainly does not work in all of them.

> [...]
> However resulting string definitely varies among implementations. In
> Opera 7.54, for example:
>
> var x = 'a\
> b';
>
> x === 'a\u000Ab'; // true

I rest my case. The correct value would have been `false'.

> Note how there's a line feed (U+000A) in between 2 characters.

Tell me something I don't know yet.

> In Opera 8.01 (and later), `x` already evaluates to 'ab'.

Interesting. Apparently it has worked for a short time in-between the
versions I have tested this feature so far (5.02, 6.06, 10.10). More fine-
tuned testing is clearly indicated. However, there can be no doubt that
this feature is not safe for general use for the time being.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Garrett Smith on
Stefan Weiss wrote:
> On 02/02/10 16:47, Matt Kruse wrote:
>> In my Greasemonkey code written specifically for Firefox, I use this
>> "heredoc" syntax a lot:
>>
>> var myBigBlob = (<><![CDATA[
>>
>> ... insert a bunch of free-form text here ...
>>
>> ]]></>).toString();
>>
>> Now that Chrome offers built-in Greasemonkey support, I'd like to
>> support it as well, but it breaks on this syntax.
>>
>> Does anyone know of a better method that will work in both browsers?
>
> Sorry, I don't. I've always wondered why multi-line string literals
> aren't possible in JavaScript. AFAICS, there's nothing ambiguous about
> this syntax:
>
> var heredoc = "I am a multi-line
> string; I end when the tokenizer
> sees a double quote";
>
> This is standard practice in many other programming languages. Maybe ES4
> had something like this in the queue, but with ES5 geared towards
> backwards compatibility, we probably won't see it for a long time.
>
> The two usual workarounds are
>
> var str = "I wish\n"
> + "I was\n"
> + "a multi-line string";
>
> and
>
> var str = "I am the closest thing\
> to multi-line strings that we can get\
> with JavaScript";
>
> I don't know how well supported the second version is. At least the
> first version will can optimized into a single string when it's
> processed with a minimizer.
>

Says in Ecma 262r3:
7.3 Line Terminators
A line terminator cannot occur within any token, not even a string.

It seems unsafe to rely on that. It might produce the desired outcome,
but if that failed, then it would be your fault.

Seems to have changed in ES5.

Ecma 262r5
7.3
| Line terminators may only occur within a StringLiteral token as part
| of a LineContinuation.

And

| A line terminator character cannot appear in a string literal, except
| as part of a LineContinuation to produce the empty character sequence.
| The correct way to cause a line terminator character to be part of the
| String value of a string literal is to use an escape sequence such as
| \n or \u000A.

And
| The SV of LineContinuation :: \ LineTerminatorSequence is the empty
| character sequence.

Good to see you back, BTW.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on
Garrett Smith wrote:

> Stefan Weiss wrote:
>> [...]
>> var str = "I am the closest thing\
>> to multi-line strings that we can get\
>> with JavaScript";
>>
>> I don't know how well supported the second version is. At least the
>> first version will can optimized into a single string when it's
>> processed with a minimizer.
>
> Says in Ecma 262r3:
> 7.3 Line Terminators
> A line terminator cannot occur within any token, not even a string.
>
> It seems unsafe to rely on that. It might produce the desired outcome,
> but if that failed, then it would be your fault.
>
> Seems to have changed in ES5.

Good morning, sunshine.

<news:1325016.AFRqVoOGUt(a)PointedEars.de>


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee