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: Thomas 'PointedEars' Lahn on 24 Oct 2009 14:01 VK wrote: > 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. Brendan Eich is at least in the contributor's list for all three Editions of the ECMAScript Language Specification, and its apparently upcoming fifth Edition. You make it look instead as if the ECMAScript standardization process had/has nothing to do with him. That is extremely unfair of you given his ongoing efforts to improve the language, and quite presumptuous given that you are using it to justify your ongoing fantasies about how things would be. Go away. PointeddEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: VK on 24 Oct 2009 14:34 Gregor Kofler wrote: > For the less perceptive (like you): "default" is a reserved word in JS. The same pre-requisite asked to distinguish between literals and string values. Se also http://groups.google.com/group/comp.lang.javascript/msg/3a0cb6ffc451e69b
From: Thomas 'PointedEars' Lahn on 24 Oct 2009 14:22 VK wrote: > 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. Stop perverting the facts. It is apparently not allowed if `this' refers to the ECMAScript Global object *only* in JScript so far -- a clear *bug* (that no reasonable implementation is going to produce). In all other cases proof that it does not work has yet to be given. > 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 :) Obviously it did not cross your puny malfunctioning replacement of a mind that I never needed to delete any properties of the ECMAScript Global Object in the first place (guess why). PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Richard Cornford on 24 Oct 2009 14:44 VK wrote: > 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. Why not? Brendan Eich invented that language and Brendan Eich sat on the committee(s) that wrote the spec(s). If the committee members had any questions bout intentions they also had direct access to the answers to those questions. > 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, Netscape 4 was an ECMA 262 2nd Ed. implementation, that version of ECMAScript does not include function expressions at all. So in that environment they were a syntax extension, and probably an experimental one at that. > for Eric Lipper porting it to IE. No he didn't. at least that is not what JScript does, or ever has done. In JScript the construct:- (function f() { })(); - results in the creation of two function objects. The first during variable insanitation as the execution context is entered, which is then assigned as a property named 'f' on the applicable Variable object. The second during the evaluation of the expression, where that second function object gets called. If code in either of the two functions attempted to use the Identifier - f - to call a function then it would be he first of these two function that would be the one called. This behaviour in JScript is sufficiently irrational that there is virtually zero chance that it exists by design (i.e. it is a bug, even without considering what any ECMA standard may say on the subject), and it certainly will not represent a (sucessful) porting of anything that was done in pre-existing Netscape browsers. > 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. JScript did not claim to be a ECAM 262 3rd Ed implementation (the first version of the standard to include function expressions) before version 5.5, so while it did not make the claim it could not be faulted for not satisfying the claim. As soon as the claim to be a conforming implementation is made any failure to conform is a bug by language specification. > 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. No, that is interpreted as a syntax error. Labelled statements, being statements, cannot appear on the right hand side of a comma operator (only an Expression may appear in that context). Changing the comma to a semi-colon, or just removing the comma while retaining the line terminator, removes the syntax error, but both actions preclude even the possibility that the construct be used in an object literal context a then it becomes a different syntax error. > { > 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. Which might be more meaningful if you first example had not also been a 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. Haven't I already pointed out what a nonsense this proposal that some sort of 'automatic quote insertion' happens during tokenising/parsing is? I suppose that just went straight over your head again. If that could happen then all sorts of possibilities would come into play. Rather the situation is relatively simple. The evaluation of an object literal results in the creation of a new object and for each name/value pair in the literal a new named property is added to that object where the rules for determining the character sequence in that name are:- if the name part is an Identifier then the character sequence from the Identifier is used as the new property's name, if the name part is a string literal then the character sequined from the string literal is used as new property's name, and if the name part is a numeric literal that is evaluated to produce the number value and that numeric value is type-converted into a string, and then that character sequence form that string is used as the new property's name. There is no need to propose any automatic insertion of quotes into the source text (or token stream) in order to account for the behaviour seen. And indeed such insertions would be contrary to the behaviour observed. For example:- var x = { x-y:5 }; - is a syntax error but:- var x = { 'x-y':5 }; - is not. The first being a mathematical expression in a context that only allows for Identifiers, string literals and numeric literals, while the second is a numeric literal. There is no reason for any 'automatic quote insertion' not to accommodate the former. var x = { x:1,y:2 }; - is a valid object literal, and so is:- var x = { 'x:1,y':2 }; Similarly:- var x = { ':::::':0 }; - is a valid object literal, but:- var x = { ::::::0 }; - never could be, except that, if they existed, it could be rendered valid by some sort of 'automatic quote insertion' rules. var x = { '@@@@@':0 }; - is fine, but you won't get awya with:- var x = { @@@@@:0 }; > 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. Only in the sense that the behaviour resulting form the use of an identifier in the name part of an object literal is already well defined. > 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: You see, your over-elaborate fantasy of 'automatic quote insertion' needs a whole list of special cases to account for what javascript actually does. You have problems accounting for any used of key/reserved words, for expressions, for unexpected character sequences. So on top of what you have you also need a massive array of additional rules. The alternative of, if it is an Identifier, a string literal or a numeric literal it will be predictably handled, and if it is not then a syntax error should be expected, covers the situation nicely. And if some implantations want to extend either the definition of Identity, or the named part of an object literal, to include reserved words then that does not introduce much additional complexity. I find it humorous that your profile in Google groups quotes Ockham's Raiser in Latin, as I cannot think of any better demonstration of spectacularly missing the point. Here we have a case where the simpler explanation certainly is the better explanation. > now no, it is not a constructor but a block of > statements with the second one preceded by an illegal > label literal. No it isn't. It is just an object literal that contains a syntax error. Earlier today you were asserting that including the 'default' in an object literal was resulting in its interpretation as a "a broken switch-case construction", and I asked you what evidence you had for that assertion. You never were going to provide any such evidence as you never had any. Instead you had just made that assertion up off the top of your head. Here again you are making this up off the top of your head. For a start, the interpreter is very unlikely to ever switch to attempting to interpret this as a Block statement for the simple reason that no Statement is allowed to be the right hand side of an assignment operation. By the time the parser has seen the assignment operator (the single = sign) we are in an Expression context, and the only question is whether what follows is a syntactically correct Expression or not. > Some might find it very logical. I am definitely not in > that club. If even you do not find your own fantasies logical why do you bother anyone else with them? Richard.
From: Thomas 'PointedEars' Lahn on 24 Oct 2009 14:41
Richard Cornford wrote: > There is no need to propose any automatic insertion of quotes into the > source text (or token stream) in order to account for the behaviour > seen. And indeed such insertions would be contrary to the behaviour > observed. For example:- > > var x = { > x-y:5 > }; > > - is a syntax error but:- > > var x = { > 'x-y':5 > }; > > - is not. The first being a mathematical expression in a context that > only allows for Identifiers, string literals and numeric literals, while > the second is a numeric literal. ^^^^^^^ Do you mean "string"? As for the rest, thank you for your patient explanations. One can only hope something of it gets through to him. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |