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 26 Oct 2009 14:45 RobG wrote: > "Richard Cornford" wrote: >> Thomas 'PointedEars' Lahn" wrote: >> > As for the rest, thank you for your patient explanations. One can >> > only hope something of it gets through to him. >> >> Pigs may fly. ;-) > > While your wisdom is no doubt lost on VK, it is greatly appreciated by > others who learn by reading your responses. > > If you were to collate your posts to clj for a book along the lines of > Crockford's Good Parts, I'm sure it would quickly become a best > seller. Full ACK. I would like to volunteer for the prufreading the speling ;-) 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: VK on 28 Oct 2009 18:54 Richard Cornford wrote: > You stated that:- > "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." Right. > "due to some parser quirks they may lead to syntax errors" Right. > "do not use the above mentioned syntax shortcut and to use full syntax > with quotes around each property name" Right. > There is no meaning to "quotes are omitted". The names used in object > literals are one of Identifiers, string literals, or numeric literals. > String literals are not string literals without quotes and Identifiers > are not Identifiers with them. That's pretty much points to your regular problem when dealing with JavaScript, and on a bigger scale - the common problem of many regulars, getting the base of their wisdom from ECMA262 3rd.ed. ECMA262 3rd.ed. is an extremely bad source to learn the language because its main purpose is not to explain the language, but to describe the internal algorithms so make it possible to write compliant engines for other than Netscape browsers. The difference is as between say a Perl user reference and comments for C libraries used for Perl processor. As the result some regulars know some really refined internal mechanics, some of which even never did into any actual implementation, yet having troubles to get some obviousnesses. In the particular and most importantly they are normally having big time troubles to distinguish *language* features and *underlaying C-based engine* features and consequently having troubles to separate properly tokenizing, parsing and execution stages, so applying terms and entities from one stage to another and vice versa. > Allowing Identifiers may be for simplicity (or maybe just because it > seemed like a good idea, or was so obvious that it was never questioned > and so has no motivation). There is no sense in "omitting" quotes being > "allowed" for any reason, what is allowed is a choice of tokens. One more time, very slow: parsed by the rule of an identifier !== to be an identifier. In object constructor all key values are string literals, explicitly or implicitly quoted. Again, we are taking about JavaScript, so about the execution stage. What and how exactly C program treats the source code stream is irrelevant here yet might be interesting in other circumstances. > > but if quotes are omitted, some troubles are possible on > > the parsing stage so better to use them. > > The only possible trouble is that if the construct created does not > conform with the syntax rules it will result in a syntax error. You call it "the only possible trouble"? It sounds like a joke "the worst what may happen with you - you may die" :) > > Simple and clear. Indeed > As with much you write, it gets clearer as you edit more out. There is > no more talk of "syntax shortcut", It is. > "full syntax with quotes around each > property name" It is the full syntax because in object constructor all key values are string literals, explicitly or implicitly quoted. Again, we are taking about JavaScript, so about the execution stage. What and how exactly C program treats the source code stream is irrelevant here yet might be interesting in other circumstances. > "the quotes will be added automatically" See right above. > "one of reserved > words in the parser list AND it changes its own previous decision" Right, and this is one of weak points of the current parser rules. Yet I understand that the productivity impact to accommodate this problem may be to serious to be practical. > "it > is not a constructor but a block of statements", "consider such code as > a broken switch-case construction", etc. Here my interpretation was wrong. "False positive" because of "default" keyword as the troublemaker. Do not forget that the problem was obscured by say var obj = {class: 'foobar'} being just fine on Gecko, so it took a really unusual combination of factors to get an object constructor, being to lazy at the moment to type quotes and thinking that "default" as the last key would be a good name here. Yet you may order some champagne to celebrate if you wich :) > You mean they are processed as Identifiers if they are Identifiers? > > > They are not identifiers > > Yes they are. No they are not. See the preface of this post. You need to learn to distinguish the language and the underlaying engine. > > and they are not becoming identifiers out of being processed > > by this rules. > > If they were not Identifiers they would not be processed as Identifiers. .... still long way to go with you... An identifier, an expression, an object, a function are entities distinguished by their functions and by their usage in the *language*. Can you make an effort and to get out from the irrelevant lower level matters? It is JavaScript forum and we are talking about JavaScript here, not about C or C++ and how these languages are used to produce a functional JavaScript program out of the source text. The rest of post is the same delusion (or a trick?) to talk about JavaScript running program, source code, C/C++ parser rules at once in one sentence without any proper attribution of relevant parts to relevant aspect.
From: Lasse Reichstein Nielsen on 29 Oct 2009 03:11 VK <schools_ring(a)yahoo.com> writes: > That's pretty much points to your regular problem when dealing with > JavaScript, and on a bigger scale - the common problem of many > regulars, getting the base of their wisdom from ECMA262 3rd.ed. > ECMA262 3rd.ed. is an extremely bad source to learn the language Agree. > because its main purpose is not to explain the language, but to > describe the internal algorithms so make it possible to write > compliant engines for other than Netscape browsers. No, it's purpose is to *define* the language. Not the internal algorithms, but the syntax and semantics of it. The algorithms given in the specification is not something you must follow, as long as what you do gives the same result. I must admit that there are places where the format has affected the specification more than I think is necessary. In this case, that's not relevant, though, because we are talking about syntax. > The difference is > as between say a Perl user reference and comments for C libraries used > for Perl processor. > As the result some regulars know some really refined internal > mechanics, some of which even never did into any actual > implementation, yet having troubles to get some obviousnesses. In the > particular and most importantly they are normally having big time > troubles to distinguish *language* features and *underlaying C-based > engine* features and consequently having troubles to separate properly > tokenizing, parsing and execution stages, so applying terms and > entities from one stage to another and vice versa. I do think you have a point, but your presentation of the point is marred by you making the same mistake of mixing terminology from different phases. > One more time, very slow: parsed by the rule of an identifier !== to > be an identifier. Here you seem to have an idea what it means to be an "identifier". In Javascript, being an identifier is a tokenization concept. The thing you seem to think about is called "variable". > In object constructor all key values are string > literals, explicitly or implicitly quoted. The concept of "string literal" is again a tokenization/parsing concept. String literals are sequences of characters flanked by either single or double quotes. They are parsed, and evaluated into string values. You cannot quote a string value. Being quoted is a syntactic concept, which happens even before tokenization. > Again, we are taking about > JavaScript, so about the execution stage. What and how exactly C > program treats the source code stream is irrelevant here yet might be > interesting in other circumstances. Which is, perhaps, why your explanation isn't being accepted - you uses parsing/tokenization concepts it. .... >> "full syntax with quotes around each >> property name" > > It is the full syntax because in object constructor all key values are > string literals, explicitly or implicitly quoted. Again, we are taking > about JavaScript, so about the execution stage. What and how exactly C > program treats the source code stream is irrelevant here yet might be > interesting in other circumstances. > >> "the quotes will be added automatically" > > See right above. You can't add quotes after tokenization, so if you say that quotes are added, it must be at the level of tokenization, at the latest. My guess is that this better matches what you mean: In object literals, all keys are string values. They can be written as string literals, or as identifiers or number literals, which is then converted to string values. Identifiers may not include language keywords, and numbers are always converted to their canonical string form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Thomas 'PointedEars' Lahn on 29 Oct 2009 04:31 Lasse Reichstein Nielsen wrote: > VK <schools_ring(a)yahoo.com> writes: >> That's pretty much points to your regular problem when dealing with >> JavaScript, and on a bigger scale - the common problem of many >> regulars, getting the base of their wisdom from ECMA262 3rd.ed. >> ECMA262 3rd.ed. is an extremely bad source to learn the language > > Agree. IBTD! PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: VK on 29 Oct 2009 12:36
VK writes: > > parsed by the rule of an identifier !== to > > be an identifier. Lasse Reichstein Nielsen wrote: > Here you seem to have an idea what it means to be an "identifier". > In Javascript, being an identifier is a tokenization concept. The > thing you seem to think about is called "variable". No, I think exactly about *identifiers*. Identifiers and variables are circa in the same relations as human names and human beings themselves. One person can have several names (Edgar Allan Poe) and several people can have the same names being distinguished by other criteria (addresses etc.) Again: http://en.wikipedia.org/wiki/Identifier#Identifiers_in_computer_languages "In computer languages, identifiers are tokens (also called symbols) which name language entities. Some of the kinds of entities an identifier might denote include variables, types, labels, subroutines, and packages." http://en.wikibooks.org/wiki/C++_Programming/Code/Style_Conventions/Naming_identifiers "Identifiers are names given to variables, functions, objects, etc. to refer to them in the program." The purpose of an identifier is to name something, it is its core feature and it implies its univalence within the given scope. Other words identifier foo may identify the most different variables on each program step (foo=true; foo=bar; foo=null) but it must not identify two or more different variables at the same time as it ends the program integrity. And no, identifiers in JavaScript do not have some special naming- unrelated function, let's not pretend that JavaScript is from Mars while all other programming languages are from Jupiter. Higher level entities may bear different meaning by languages, say "static" method in C, Java and Visual Basic/VBA mean such different things that they have nothing in common at all, except the same six letters used to denote them. But the core entities (algorithm, program, condition, identifier, subroutine etc.) are the same irrelevant to possible verbal oopses in this or that document. VK writes: > > In object constructor all key values are string > > literals, explicitly or implicitly quoted. Lasse Reichstein Nielsen wrote: > The concept of "string literal" is again a tokenization/parsing > concept. String literals are sequences of characters flanked by either > single or double quotes. They are parsed, and evaluated into string > values. > You cannot quote a string value. Being quoted is a syntactic concept, > which happens even before tokenization. var foo = 'bar'; var obj = {foo : true}; Will it produce obj with property name 'foo' or with property name 'bar'? Is the result caused by parser rules or by language rules stating that in this particular position it must be a string literal, either programmer surrounds it by quotes or not? .... > You can't add quotes after tokenization, so if you say that quotes > are added, it must be at the level of tokenization, at the latest. Disagree with you on that as it implies some mechanicism of the worst kind in the whole programming (not JavaScript only) with the programmer being some toy in hands of "pre-programmed elements". If a programmer types: var foo = 'bar'; var obj = {foo : true}; he means something at the moment of typing, same way as with the casual writing. If he means "use the string value 'bar' identified by foo as the property name in obj" then he simply makes a program mistake. If he properly means "use string literal 'foo' as property name in obj" then it is the implicit quoting provided by the language and used by the programmer: and the implicit quoting happens right here and then, on typing, not some later out of "good heartiness" of some C subroutine. To make it even more clearer let's take Perl where this convenience typing shortcut was taken from into JavaScript back in 1995: %obj = ( foo => 'bar', bar => 'foo' ); Are we having here foo and bar "identifiers" that become string literals on the parsing stage? Of course not, these are string literals written by the programmer using documented shortcuts. > My guess is that this better matches what you mean: > > In object literals, all keys are string values. They can be written > as string literals, or as identifiers or number literals, which is > then converted to string values. Identifiers may not include language > keywords, and numbers are always converted to their canonical string > form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted. Something that cannot be an identifier or number in a given position cannot be written "as identifiers or number literals". Yes, a convenience shortcur was taken but the necessary parser logic was not added to save on parsing time and now it is necessary to deal with it: but without introducing "non-identifier identifiers", deferred to the parsing stage programming logic and similar bizzarities. IM_strong_yet_HO |