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 10:51 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, Thomas 'PointedEars' Lahn wrote: > `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). Do you understand the difference between literal values and string values? One cannot have var class = 'foo'; but it is perfectly OK to have myObject['class'] = 'foo'; 'default' in the quoted context is a string to use as key name, no way it can be treated as a literal. JavaScript provides Perl-like shortcut syntax with key string quotes omitted to save "poor programmer's fingers" and to improve(?) code readability - and respectively automatically added by the parser. For me it is obvious that all parsers but Fx's are fubar on at by treating a shortcut syntax of a key string as a literal. Just another prove of my old credo: never economize on keystrokes and don't let other do it as well, this is cheapest resource to spend.
From: Richard Cornford on 24 Oct 2009 11:00 Evertjan wrote: > VK wrote on 24 okt 2009 in comp.lang.javascript: <snip> >> 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. But the need in JSON follows from its use with unknowable data sources where the character sequences that will end up in the keys are unpredictable. For a programmer writing an object literal the character sequence that will be the key is known at the point of writing it, and so knowing the syntax rules for the object literal construct allows them to either see when the names they want to use need special handling or to question their choice of names. Blanket rules are not necessary in that context, and their application risks the "programmers" being drawn into a world of chanting sequences of mystical incantations in place of understanding what they are doing. It is interesting to note that JSON not only requires that all the keys be quoted, but that they be quoted with the double quote character (as opposed to the apostrophe). It is easy to see how such simplifications of format ease the string-based processing of the data. Richard.
From: VK on 24 Oct 2009 11:04 Richard Cornford wrote: > (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.) Surprisingly for you I do, because I am doing what my clients do need and I am heavily indifferent in this aspect on what some c.l.j. regulars want to see. Sometimes I am getting really strange situations caused by some obscure specs or implementation quirks and then I let guys like you to get their $40-$60/hour geek plus free coffee and doughnuts - but most of the time they are not needed so it is times cheaper to keep a verified freelancers' list rather than to keep it on salary + benefits ;)
From: Thomas 'PointedEars' Lahn on 24 Oct 2009 11:10 VK wrote: > Thomas 'PointedEars' Lahn wrote: >> `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). > > Do you understand the difference between literal values and string > values? One cannot have > var class = 'foo'; > but it is perfectly OK to have > myObject['class'] = 'foo'; Red herring. We are not talking about variable declarations or property accessors here; we are talking about Object initializers. > 'default' in the quoted context is a string to use as key name, Often Wrong, there are no keys. (_Property names_ are always strings, but that does not matter here.) There is an /Expression/ here that can only be produced by the /ObjectLiteral/ production. And the grammar for that /ObjectLiteral/ requires that the part before the `:' (which I called "name part") be either an /Identifier/, a /StringLiteral/, or a /NumericLiteral/. `default' is neither -- so syntactically invalid. As a result, e.g. my IE, too, reports what Richard already said. Your placing either <'> or <"> around `default' makes it being producable by the /StringLiteral/ production again -- so syntactically valid. It is simple, relentless mechanical logic that is at work here, and despite two detailed explanations you are still incapable to get it. 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: Richard Cornford on 24 Oct 2009 11:45
Hans-Georg Michna wrote: > 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? Is that true? A lot of things get attributed to Douglas Crockford without there being any evidence of them being attributable to him. I would expect that if he had made such an injection it would be found in the text of his "JavaScript: The Good Parts" (if not in many other places as well). Looking tat that book, in Appendix A "Awful parts", under the heading "Reserved Words" (page 103) he writes:- Most of these words are not used in the language. They cannot be used in name variables or parameters. When reserved words are used as the keys in object literals they must be quoted. They cannot be used with the dot notation, so it is sometimes necessary to use the bracket notation instead: <RC: followed by a list of examples > - where the opportunity to propose some SHOULD-style injections is not taken up. There are also many examples of object literals in the book where no blanket quoting of keys is evident, for example, on page 25 under the heading "Global Assignment". Then there is his JSLInt program. There are a number of 'rules' imposed by JSLint that are the direct result of Douglas Crockford's conclusions about 'correct' style in javascript authoring. If he believed that it was a good idea for keys in object literals to always be quoted without exception then he could easily program such a 'rule' into JSLint. So, going to:- <URL: http://www.jslint.com/ > - and entering VK's original code the error reported is "Problem at line 4 character 3: Expected an identifier and instead saw 'default' (a reserved word)", as could have been expected. adding quotes to just the - default - keyword in the code removes that error message, but does not produce any error messages about the other keys not being quoted. And looking at the options further down the page does not even suggest a possible of turning such warnings on (at least outside of the possibility of explicitly testing JSON text with JSLint, where you expect JSON rules to be applied). > If I'm not mistaken, he has also made this a part of the JSON > standard. Maybe the "also" does not belong in that sentence. > Anyway, it may be worth reading his recommendations and perhaps > use JSLint, which would have alerted you to the problem well in > time. Or just learning the syntax rules. VK claims to have been writing javascript for well in excess of 10 years, so his not already being familiar with object literal syntax rules is a little incredible (at least if the initial claim was regarded as credible). Richard. |