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 24 Oct 2009 09:56 Just nailed down a spurious bug from a 3rd party code which seems to be in unexpected continuation of "Little Help with JavaScript" side discussion and Mr.Cornford comments: http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265cb5 The minified test case: var test = { op1 : false, op2 : false, default: false } window.alert(test.default); Leads to the syntax error on all test set browsers but Firefox where it expectedly (? unexpectedly ?) reports that test.default = false The others (IE, Safari, Chrome, Opera) do consider such code as a broken switch-case construction so reporting the missing switch clause. By taking default key into quotes such reading goes away: var test = { op1 : false, op2 : false, 'default': false } window.alert(test.default); // false I honestly don't give a damn what ECMA says on it, it sucks even carved somewhere on a stone. With this and the preceding label vs key issue the safe coding policy will be changed: it will be required in the office and from subcontractors to use explicit quoting of object key values and do not ever relay on the implicit one. The group readers may or may not account this coding advise.
From: Thomas 'PointedEars' Lahn on 24 Oct 2009 09:59 VK wrote: > Just nailed down a spurious bug from a 3rd party code which seems to > be in unexpected continuation of "Little Help with JavaScript" side > discussion and Mr.Cornford comments: > http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265cb5 > > The minified test case: > > var test = { > op1 : false, > op2 : false, > default: false > } > > window.alert(test.default); > > Leads to the syntax error on all test set browsers but Firefox where > it expectedly (? unexpectedly ?) reports that test.default = false Whereas the error is not caused by the window.alert(...) call, of course. > The others (IE, Safari, Chrome, Opera) do consider such code as a > broken switch-case construction so reporting the missing switch > clause. By taking default key into quotes such reading goes away: > > var test = { > op1 : false, > op2 : false, > 'default': false > } > > window.alert(test.default); // false > > I honestly don't give a damn what ECMA says on it, And exactly that is the problem with you. You rather make up fancy stories (here: about switch-case misrecognition) instead. `default' is a keyword; it may not be used as identifier in an ECMAScript-3 compliant /Program/ (ES3F, 7.5.2). And when not a /StringLiteral/ or a /NumericLiteral/, the name part in an /ObjectLiteral/ must be an /Identifier/ (ES3F, 11.1.5). Mozilla.org JavaScript's deviation is either a bug, an implementation of behavior specified by ES5 (FD), or an implementation of ES3F's Conformance section where it says: | A conforming implementation of ECMAScript is permitted to support program | and regular expression syntax not described in this specification. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Evertjan. on 24 Oct 2009 10:35 VK wrote on 24 okt 2009 in comp.lang.javascript: > Just nailed down a spurious bug from a 3rd party code which seems to > be in unexpected continuation of "Little Help with JavaScript" side > discussion and Mr.Cornford comments: > http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265c > b5 > > The minified test case: > > var test = { > op1 : false, > op2 : false, > default: false > } > > window.alert(test.default); > > Leads to the syntax error on all test set browsers but Firefox where > it expectedly (? unexpectedly ?) reports that test.default = false > > The others (IE, Safari, Chrome, Opera) do consider such code as a > broken switch-case construction so reporting the missing switch > clause. By taking default key into quotes such reading goes away: > > var test = { > op1 : false, > op2 : false, > 'default': false > } > > window.alert(test.default); // false > > I honestly don't give a damn what ECMA says on it, it sucks even > carved somewhere on a stone. With this and the preceding label vs key > issue the safe coding policy will be changed: it will be required in > the office and from subcontractors to use explicit quoting of object > key values and do not ever relay on the implicit one. The group > readers may or may not account this coding advise. "> Just nailed down ... " ?? The writer of Jason knew this already, [that keys should but do not always condone reserved words] it was the reason that he required all keys to be quoted. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Hans-Georg Michna on 24 Oct 2009 10:42 On Sat, 24 Oct 2009 06:56:27 -0700 (PDT), VK wrote: >... By taking default key into quotes such reading goes away: > > var test = { > op1 : false, > op2 : false, > 'default': false > } > >window.alert(test.default); // false > >I honestly don't give a damn what ECMA says on it, it sucks even >carved somewhere on a stone. With this and the preceding label vs key >issue the safe coding policy will be changed: it will be required in >the office and from subcontractors to use explicit quoting of object >key values and do not ever relay on the implicit one. The group >readers may or may not account this coding advise. If my memory serves me well, this is an old hat among several similar ones. Douglas Crockford, for example, has been preaching about this. He essentially says that JavaScript is a language with a number of well-known flaws, and he recommends to work around them conscientiously by using defensive strategies, usually a particular coding style and the avoidance of poor language elements. In this particular case I believe he recommends always to use quotes around property names in object literals, right? If I'm not mistaken, he has also made this a part of the JSON standard. Anyway, it may be worth reading his recommendations and perhaps use JSLint, which would have alerted you to the problem well in time. Hans-Georg
From: Richard Cornford on 24 Oct 2009 10:49
VK wrote: > Just nailed down That is hugely unlikely. You may have just misattributed something but nailing things down is not in your skill set. > a spurious bug from a 3rd party code which seems to > be in unexpected continuation of "Little Help with JavaScript" > side discussion and Mr.Cornford comments: > http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265cb5 > > The minified test case: > > var test = { > op1 : false, > op2 : false, > default: false ^^^^^^^ The ES 3 rules for object literals requires that the name in any name/value pair be either an Identifier, a string literal or a numeric literal. The word "default" is a keyword and Identifiers are not allowed to be keywords (or reserved words, though some implementations are tolerant of the latter while not allowing the former). This restriction on the possibilities for the name in a name/value pair in an object literal explains why IE produces the syntax error "Expected Identifier, string or number." when asked to process this code (which is even unusually explicit for a JScript error message). It is expecting an Identifier, string or number, but instead encountered a keyword. > } > > window.alert(test.default); > > Leads to the syntax error on all test set browsers but Firefox > where it expectedly (? unexpectedly ?) reports that > test.default = false There were plans for ES 5 to remove the restriction as the use of keywords (and/or reserved words) in that context does not lead to ambiguities in interpretation. And because of the lack of resulting ambiguities it is possible for any ECMA 262 implementation to tolerate keywords in such a context as a syntax extension. > The others (IE, Safari, Chrome, Opera) do consider such code > as a broken switch-case construction What evidence do you have that any of them are interpreting it as "a broken switch-case" when any syntax errors they report are much more likely to be the direct result of its being the broken object literal that it is? As I said, it was pretty certain that you had not actually nailed anything down, and were going to be miss-attributing something. Here it is; "a broken switch-case construction" when the code in question is pretty obviously a broken object literal. > so reporting the missing switch clause. "Expected Identifier, string or number."? > By taking default key into quotes such reading goes away: because that is a string in place of a keyword. > var test = { > op1 : false, > op2 : false, > 'default': false > } > > window.alert(test.default); // false > > I honestly don't give a damn what ECMA says on it, Well, (and assuming that you are honestly reporting the situation and did not write this code yourself) if whoever wrote it had given a damn, or even just tested in a few other environments, they you would never have been asked to deal with the consequences. The syntax error is there, and so getting syntax error messages from web browser always was that likely outcome. > it sucks even carved somewhere on a stone. The fact that the injunction on keywords in that context can be changed means that it never was necessary. However, there may have been a time when the simplicity of distinction between things that were Identifiers and things that were not made for faster tokenising/parsing/compiling on hardware that was not nearly as capable as current hardware. > With this and the preceding label vs key issue the safe > coding policy will be changed: it will be required in > the office and from subcontractors to use explicit quoting of object > key values and do not ever relay on the implicit one. That is you all over; a knee-jerk over-generalised overreaction to being caught out once again by your not knowing the syntax rules of the language you are using. (Incidentally, the "office" delusion is interesting, as you are such an appalling programmer that it is literally increasable to suggest that you have any colleagues that are capable of programming at all and that you maintain employment in such an environment.) > The group readers may or may not account this coding advise. You mean when the advice to write javascript that conforms with ECMA 262 syntax rules will get the job done with less effort? Richard. |