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: Evertjan. on 24 Oct 2009 12:02 Richard Cornford wrote on 24 okt 2009 in comp.lang.javascript: >> 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 True, but the reserved word list is crossbrowserly perhaps knowable, but illogical. > 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. Perhaps ours is not to reason why [cf Alfred Lord Tennyson], but I wrote it to show the reasoning, not as a general advice to be followed up. A parallel is the [ugly?] habit to [] fieldnames in sql strings, also to preclude possible reserved word errors. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: John G Harris on 24 Oct 2009 12:31 On Sat, 24 Oct 2009 at 06:56:27, in comp.lang.javascript, VK wrote: <snip> >I honestly don't give a damn what ECMA says on it, it sucks even >carved somewhere on a stone. <snip> The man who invented the language said it must be like that. Get used to it. If you can't, find another language. John -- John Harris
From: VK on 24 Oct 2009 12:33 Richard Cornford wrote: > 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). As this being attributed to VK I do answer: exactly because I am in the commercial programming since late 1996 with two "wars" behind (the Big One of 1996-1998 and the "religious" one of 2005-2008) many things just don't occur on me because I almost subconsciously do not do this or do that in only that way. With years some harmless(?) cargo cult gets accumulated of course: say pre- declaring all vars over assignment of the supposed type values. At the same time I am indifferent to any fine-tune language properties if they lead to a discussion of professional programmers. Because if there is a discussion then there are at least two possible readings and it is absolutely non important then what reading is the right one or what reading is the utterly wrong one, or if both are possible: by the 1st Murphy's law there already are or soon will be at least two environments implementing different reading options. This way you code needs to avoid this particular coding approach ever since and forever. This is why some c.l.j. regulars are sometimes a shocking experience to me. One moment they are showing some deepest knowledge of some really obscure language corners no one else - including engine implementors - cared about, and the next time showing shocking naiveness in the most obvious parts of the practical programming. Say Thomas 'PointedEars' Lahn really killed me recently after years of quoting to death different papers and then not knowing that delete this.val is not allowed at least in IE. For me it's like if someone knows by heart all von Clausewitz and all field regulations yet not able to reload his own rifle :) Some don't believe I can be in a programming business. Well, sometimes I am getting - surely very wrong - impression if some posters produced any commercial code in their lives.
From: Richard Cornford on 24 Oct 2009 12:56 Evertjan wrote: > Richard Cornford wrote on 24 okt 2009 in comp.lang.javascript: > >>> 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 > > True, but the reserved word list is crossbrowserly perhaps knowable, > but illogical. Knowable, because ECMA 262 states the list. How logical the list may be probably depends on perspective. In retrospect words like - let - and - unit - should have been in the list (as they are things people now want in the language, and can only be introduced on a context-dependent basis) and all the class-based stuff need never have been there. In the past, when the stated intention was to migrate javascript towards being more Java-like they probably made sense. Certainly the list is something that is relatively easy to trip over. I have changed the syntax highlighting rules in my text editors so that reserved words are displayed in in very obvious 'red on a bright yellow background' so that I will easily notice my attempts to use them as variable names. Specifically, if I want a variable to hold a single character from a string I am always tempted to name it "char", and over tolerant environments often put up with that, while one or two do not. No amount of quoting the keys in object literals is going to help there as variable names cannot ever be quoted, so the syntax highlighting is probably the best general solution (it is just a pity that text editors I use have too few categories to make devoting one to keywords a convenient action). >> 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. > > Perhaps ours is not to reason why [cf Alfred Lord Tennyson], I am not someone who is going to be found charging a gun emplacement on horseback armed only with a spear, regardless of any 'authority' telling me to. ;-) > but I wrote it to show the reasoning, > not as a general advice to be followed up. > > A parallel is the [ugly?] habit to [] fieldnames in sql strings, > also to preclude possible reserved word errors. I really don't know enough about SQL to judge (that is the server-side programmer's responsibility), though I can't say I have noticed this in the SQL I have been exposed to. Richard.
From: VK on 24 Oct 2009 13:12
John G Harris wrote: > The man who invented the language said it must be like that. Get used to > it. > > If you can't, find another language. I wouldn't put the strict equality sign between what the Man did and what others (ECMA freelancers) managed to write about it. Say it was obvious for the Man that in case (function f() { })() function f being created and added to the namespace. It was so for him, for NN2.x-4.x, for Eric Lipper porting it to IE. Only much later during the "hand-pointer" opposition stage some read out an alternative meaning from ECMA to make IE wrong in yet another small but pleasurable point. On the topic and if you manage to fight over the regular "get VK!" instincts than you see that: { a: "a", b: "b" } is interpreted as a block with a and b label literals. { a: "a", "b": "b" } is interpreted as a block with a and b label literals where b is illegal as we cannot use string value instead of literal so syntax error. var obj = { a: "a", "b": "b" } creates the necessary interpretation context so the right part is treated as an object constructor and the automatic quoting gets on, so we may quote the keys, do not quote them or do quote them zebra-style or whatever. Even if the very first key is not quoted, it is still interpreted as key string value, because the "interpretation decision" is being made before that. var obj = { a: "a", "default": "b" } absolutely the same as before, the "interpretation decision" is being made before entering so it is already decided that it is an object constructor and not a block of statements, so it is irrelevant that the first key is not quoted: the quotes will be added automatically. var obj = { a: "a", default: "b" } the "interpretation decision" is being made before entering so it is already decided that it is an object constructor and not a block of statements, so it is irrelevant that the first key is not quoted: the quotes will be added automatically; THEN the system meets [default] chars sequence which corresponds to one of reserved words in the parser list AND it changes its own previous decision: now no, it is not a constructor but a block of statements with the second one preceded by an illegal label literal. Some might find it very logical. I am definitely not in that club. |