Implicit object constructor misinterpretation
in [JavaScript]
|
Prev: Are arguments that are objects passed by reference?
Next: FAQ Topic - How do I access a frame's content? (2009-10-25)
From: VK on 25 Oct 2009 13:58 Thomas 'PointedEars' Lahn wrote: > >> `foo' is called an identifier because it must be produced by the > >> /Identifier/ production. VK wrote: > > Almost perfect, one half in there already! Thomas 'PointedEars' Lahn wrote: > You must be kidding. Deadly serious. You just keep thinking over it - the main part of the path is already done. btw somehow I overlooked the answer of Brendan Eich to my post at mozilla.dev.tech.js-engine Who doesn't have this group and doesn't want to use GG I am copying it here: > > > VK wrote: > > > > Having a statement such as: > > > > var obj = { > > > foo: 'bar', > > > default: 'default_value' > > > } > > > > Firefox 3.5.3 creates obj with properties foo and default. > > > > IE reports syntax error "Expected identifier, string or number", same > > > or similar syntax error occurs on Safari, Chrome and Opera. By placing > > > default into quotes we are making the code valid for all browsers in > > > question: > > > > var obj = { > > > foo: 'bar', > > > 'default': 'default_value' > > > } > > > > My question is if it is a Gecko bug, a convenience extension or the > > > proper implementation by ECMA with others being wrong on that? > > Brendan Eich wrote: > Not a bug, yes a convenience, and proper implementation of ES5 (after > ES3.1 and ES4, which both allowed reserved words to be used in > property-name contexts). Also a proper extension to ES3, which allows > such syntactic extensions (see chapter 16). > > IE has yet to ship the ES5 JScript implementation I've seen demo'ed at > Ecma TC39 meetings. So it is as as earlier explained: property names are strings, explicitly quoted or implicitly quoted. Brendan Eich refers to ECMA 262 3rd.ed. Chapter 16 "Errors" http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf and logically I do agree with him: if a non-quoted character sequence in this position is guaranteed to be quoted (treated as a string literal on the execution stage) then it is really not a parser's monkey business to check its language naming conformance or check it against a reserved words table. Any way coming back to the same: ////////////////////// // explanation starts Object constructor property names are always treated as string literals, so quotes around them may be omitted in the source code to speed up typing and/or for a better code readability. The drawback of such syntactical shortcut is that then all property names have to obey the JavaScript naming rules and not be equal to any of JavaScript reserved words: otherwise due to some parser quirks they may lead to syntax errors. This way it is highly suggested do not use the above mentioned syntax shortcut and to use full syntax with quotes around each property name. var obj = { foo : 'bar' // no doughnuts! } var obj = { 'foo' : 'bar'// good boy! } // explanation ends //////////////////////
From: Thomas 'PointedEars' Lahn on 25 Oct 2009 16:18 VK wrote: > Thomas 'PointedEars' Lahn wrote: >> >> `foo' is called an identifier because it must be produced by the >> >> /Identifier/ production. > > VK wrote: When will you ever learn? >> > Almost perfect, one half in there already! > > Thomas 'PointedEars' Lahn wrote: >> You must be kidding. > > Deadly serious. You just keep thinking over it - the main part of the > path is already done. [...] Idiot. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Lasse Reichstein Nielsen on 25 Oct 2009 17:58 VK <schools_ring(a)yahoo.com> writes: > ////////////////////// > // explanation starts > > Object constructor property names are always treated as string > literals, so quotes around them may be omitted in the source code to > speed up typing and/or for a better code readability. That's still wrong. It's not a matter of omitting quotes, or quotes being automatically inserted. It's three different ways to specify the name of a property: - A string literal - A number literal - An identifier Each is converted to a string (yes, also the string literal - there is a difference between a string literal and a string value!). To show, once again, that it's not just a matter of omitting quotes, consider this object initializer: var obj = { "3.0" : 42, 3.0 : 37 }; Guess what is alerted by: alert([obj[3], obj[3.0], obj["3"], obj["3.0"]]); (It's "37,37,37,42", if there was any doubt) /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Richard Cornford on 25 Oct 2009 18:52 VK wrote: > Thomas 'PointedEars' Lahn wrote: >>>> `foo' is called an identifier because it must be produced >>>> by the /Identifier/ production. > > VK wrote: >>> Almost perfect, one half in there already! > > Thomas 'PointedEars' Lahn wrote: >> You must be kidding. > > Deadly serious. You just keep thinking over it - the main part > of the path is already done. btw somehow I overlooked the answer > of Brendan Eich to my post at mozilla.dev.tech.js-engine Who > doesn't have this group and doesn't want to use GG I am > copying it here: > >>>> VK wrote: <snip> >>>> My question is if it is a Gecko bug, a convenience extension >>>> or the proper implementation by ECMA with others being wrong >>>> on that? >> >> Brendan Eich wrote: >> Not a bug, yes a convenience, and proper implementation of ES5 >> (after ES3.1 and ES4, which both allowed reserved words to be >> used in property-name contexts). Also a proper extension to >> ES3, which allows such syntactic extensions (see chapter 16). <snip> > So it is as as earlier explained: property names are > strings, explicitly quoted or implicitly quoted. No they are not. In ES 5 the syntax for PropertyName in object literals is:- | PropertyName : | IdentifierName | StringLiteral | NumericLiteral The difference being that IdentifierName has replaced Identifier in the list of possibilities. With the consequence that where Identifier is defined as "IdentifierName but not ReservedWord" and so precludes ReservedWords, IdentifierName only constrains the possible character sequences used. That is, - default - satisfies the syntax rules for IdentifierName but is not an Identifier because it is a keyword, which in tern is a ReservedWord. There is still no 'implicit quoting', which, if it did exist is neither capable of explaining, or necessary to explain, the behaviour that is observable. > Brendan Eich refers to ECMA > 262 3rd.ed. Chapter 16 "Errors" > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf > and logically I do agree with him: if a non-quoted character > sequence in this position is guaranteed to be quoted (treated > as a string literal on the execution stage) "Non-quoted character sequences in this position", as you put it, are not "guaranteed to be quoted (treated as a string literal on the execution stage)". Brendan Eich has never even implied such a thing, let alone said so. Your asserting your agreement with him in this regard is seriously disingenuous. > then it is really not a parser's > monkey business to check its language naming > conformance or check it against a reserved words table. > Any way coming back to the same: > > ////////////////////// > // explanation starts > > Object constructor Object constructor? You mean object literal. ECMAScript has an "object constructor" (if not several) and it is something else entirely. > property names are always treated as string > literals, Sequences of characters in the Property Name context of the source text for an object literal are absolutely not "always treated as string literals". If they were the resulting behaviour would be contrary to the specification(s, ES 3 and ES 5) and so objectively incorrect. > so quotes around them may be omitted in the source code No. As has been pointed out previously:- var x = { ####:0 }; - is a syntax error, while:- var x = { '####':0 }; - is not. But the handling of numeric literals is also significant as the string representation of an IEEE double precision number in ECMAScript does not necessarily correspond with the sequence of characters in the numeric literal's source text. So:- var x = { '1e4': "here" }; alert('1 ' + x['10000']); //alerts - 1 undefined - alert('2 ' + x['1e4']); //alerts - 2 here - var y = { 1e4: "here" }; alert('3 ' + y['10000']); //alerts - 3 here - alert('4 ' + y['1e4']); //alerts - 4 undefined - > to > speed up typing and/or for a better code readability. Justifications for something that does not happen are a little hollow. > The drawback of such syntactical shortcut is that then all > property names have to obey the JavaScript naming rules The only way to verify that any character sequence does satisfies any particular set of rules is to first have access to all of that sequence of characters. Having acquired the character sequence and verified that it satisfies the rules for either Identifier in ES 3 or IdentifierName in ES 5, what would be the point of attempting to create a string literal from it, when it would then be necessary to re-extract that sequence of characters from the string literal in order to know what name to give to the created object property? It is much simpler to go from the Identifier or IdentifierName straight to the name of the new property. > and not be equal to any of JavaScript > reserved words: otherwise due to some parser quirks That "quirk" being conforming with the language specification? > they may lead to syntax errors. This way it is highly > suggested do not use the above > mentioned syntax shortcut Your mentioning it does not mean that it exists. > and to use full syntax What you are calling "the full syntax" is a subset of the syntax. > with quotes around > each property name. > > var obj = { > foo : 'bar' // no doughnuts! > } > > var obj = { > 'foo' : 'bar'// good boy! > } Programmers or performing seals? Richard.
From: VK on 25 Oct 2009 19:16
Lasse Reichstein Nielsen wrote: > To show, once again, that it's not just a matter of omitting quotes, > consider this object initializer: > var obj = { "3.0" : 42, 3.0 : 37 }; > > Guess what is alerted by: > alert([obj[3], obj[3.0], obj["3"], obj["3.0"]]); > (It's "37,37,37,42", if there was any doubt) I am not forcing anyone to "my universe", just explaining why am I comfortable in there. If one decides to make the interpreter dizzy or to conduct a "sh** check" on it rather than writing reliable programs than ECMA's Book of Source (Chapter 6) provide a lot of "useful" hints: var key = ''; var obj = { // 1 '3.0' : 0, '300000000000000000003' : 0, '3000000000000000000003' : 0, // 2 3.0 : 0, 300000000000000000003 : 0, 3000000000000000000003 : 0 }; for (key in obj) {window.alert(key);} // 1 verbatim verbatim verbatim // 2 3 30000000000000000000 3e+21 From the deranged perspective of my alternative universe I see no connection though of parsing rules for number literals with the topic of question which takes case much later. I am wrong, of course. ////////////////////// // explanation starts Object constructor property names are always treated as string literals, so quotes around them may be omitted in the source code to speed up typing and/or for a better code readability. The drawback of such syntactical shortcut is that then all property names have to obey the JavaScript naming rules and not be equal to any of JavaScript reserved words: otherwise due to some parser quirks they may lead to syntax errors. This way it is highly suggested do not use the above mentioned syntax shortcut and to use full syntax with quotes around each property name. var obj = { foo : 'bar' // no doughnuts! } var obj = { 'foo' : 'bar'// good boy! } // explanation ends ////////////////////// |