Prev: Can anyone recommend a JavaScript Tree with drag and drop functionality?
Next: capture external js filename
From: Thomas 'PointedEars' Lahn on 2 Feb 2010 21:37 Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> The syntax you have used to date apparently makes use of a bug in >> Gecko's ECMAScript for XML (E4X, ECMA-357) implementation. V8 breaks >> on this syntax because syntactically valid ECMAScript for XML is >> expected, and `<>' is not well-formed XML: > > "<>"..."</>" is an XMLList initializer described under ECMA-357 > section 11.1.5, so I don't see how its a bug. Thank you, that is correct. Obviously now, E4X is more complex than I/we thought. The relevant productions here are: | PrimaryExpression : | PropertyIdentifier | XMLInitialiser | XMLListInitialiser | | [...] | XMLListInitialiser : | < > XMLElementContent_opt </ > | | [...] | XMLElementContent : | XMLMarkup XMLElementContent_opt | XMLText XMLElementContent_opt | XMLElement XMLElementContent_opt | { Expression } XMLElementContent_opt | | [...] | XMLMarkup :: | XMLComment | XMLCDATA | XMLPI | | [...] | XMLCDATA :: | <![CDATA[ XMLCDATACharacters_opt ]]> | | XMLCDATACharacters :: | SourceCharacters but no embedded sequence ]]> And | 10.1.2 ToString Applied to the XMLListType | | [...] | Note that the result of calling ToString on a list of size one is | identical to the result of calling ToString on the single item | contained in the XMLList. This treatment intentionally blurs the | distinction between a single XML object and an XMLList containing | only one value to simplify the programmer's task. It allows E4X | programmers to access the value of an XMLList containing only a | single primitive value in much the same way they access object | properties. makes sure that if E4X were supported, Matt's approach would work. In fact, it should even be possible to omit the parentheses (WFM in Gecko/TraceMonkey 1.9.1.6). 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: "Michael Haufe ("TNO")" on 2 Feb 2010 22:06 On Feb 2, 8:37 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Thank you, that is correct. Obviously now, E4X is more complex than > I/we thought. <offtopic> Of course, E4X in its present state is considered a mistake by many in its current form. I wouldn't be surprised if there are no other implementations in the future. More info: https://bugzilla.mozilla.org/show_bug.cgi?id=509705#c8 http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/6566b430328bc3ef/9f9005c6525464c6 </offtopic>
From: Thomas 'PointedEars' Lahn on 2 Feb 2010 23:27 Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> Thank you, that is correct. Obviously now, E4X is more complex than >> I/we thought. > > <offtopic> It's not. > Of course, E4X in its present state is considered a mistake by many > in its current form. By whom, and do their voices count? > I wouldn't be surprised if there are no other > implementations in the future. I would: > More info: > https://bugzilla.mozilla.org/show_bug.cgi?id=509705#c8 > http://groups.google.com/group/mozilla.dev.tech.js- engine/browse_thread/thread/6566b430328bc3ef/9f9005c6525464c6 That's *one* and the same voice (Brendan Eich) in both discussions. Some with some weight no doubt, but none that provides indication that other vendors would not be implementing what is already implemented elsewhere (in JavaScript and ActionScript). In fact, the more it is used in Mozilla, and cannot be used elsewhere (as in this Greasemonkey example), the greater the pressure for other vendors to do something about that. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 3 Feb 2010 01:11 Stefan Weiss wrote: > 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"; Nothing ambiguous? To begin with, should that be the equivalent of var heredoc = "I am a multi-line string; I end when the tokenizer sees a double quote"; or var heredoc = "I am a multi-linestring; I end when the tokenizersees a double quote"; ? Besides, you forgot to consider `\"' in your description. > This is standard practice in many other programming languages. All other programming languages that I know to support this except PHP require special syntax there. So which "many other programming languages" are you referring to? > 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. You are not making sense, see below. > 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). The next release of the ECMAScript Support Matrix will feature that test case. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: John G Harris on 3 Feb 2010 09:45
On Wed, 3 Feb 2010 at 03:03:45, in comp.lang.javascript, Stefan Weiss wrote: <snip> >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"; or var heredoc = "I am a multi-line\n" "string; I end when the tokenizer\n" "sees a double quote"; 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. John -- John Harris |