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: Richard Cornford on 1 Nov 2009 19:15 VK wrote: <snip> > P.S. > var obj = new Object; > obj[0144] = true; > obj[-100] = true; > for (p in obj) {window.alert(p);} > Rather than create some really special programming terms and > almost programming schools just take that the guys were too > busy with other stuff when making JavaScript1.2 so just added > implicit constructors with syntax shortcut atop already rather > weird per-property constructor so the system is as it is but > of course without any "non- identifying identifiers" and stuff. You are gibbering incoherently again. > P.S.S. Yet of course some regulars already might have a set of > definitions for say > obj[-100] = true; > without any "implicit quoting" Yes, and given that example (though what you imagine it to be an example of is as unclear is you usually leave it) it is extremely unlikely that you understand that code to start with. Bracket notation property accessors contain an Expression between their brackets. That expression is evaluated and the results of evaluating that expression is type-converted into a string value. Upon assignment that string value is used as an argument to an object's internal [[Put]] method, which in the case of an object hat does not already have a property with the a name that corresponds with the string value, results in the creation of a property of that object which does. Now, your Expression is -100 which is not as simple an Expression as it appears. It is an underrepresented fact that javascript numeric literals cannot define negative numbers. Which brings us to another example of something that is a syntax error by specifications but could easily be accommodated if there was 'implicit quoting' or some form of 'automatic quote insertion' going on. That is:- var x = { -1:'somethong' }; - is a syntax error because the item in the property name context is none of an Identifier, a string literal or a number literal. It is an expression. However:- var x = { "-1":'somethong' }; - is fine. yet another example of a truth that is not necessarily consistent with any notion of 'implicit quoting'. So the Expression -100 is not a number literal, it is an expression consisting of the unary minus operator with a numeric literal as its operand. Thus the evaluation of the expression involves evaluating the numeric literal to a numeric value, and then applying the unary minus operator to the result, which is then a negative numeric value. > But why not just KISS ? Only to be not like everyone? Simplify that is the result of ignoring various aspects of the reality is only the illusion of simplicity. Richard.
From: Richard Cornford on 1 Nov 2009 19:15 VK wrote:> 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. Agreeing with yourself is a little redundant. I quoted those as examples of what you actually had stated, where you were trying to make out that you had actually stated something else entirely. I assume that your agreement with yourself above represents a re-iteration of your original statements. The above is, at best, a speculation about the motivation of the original creators of object literals, and a speculation about motivation with regard to something that does not apply to its subject. There is no sense in "omitted" as not having quotes around the property name part of an object literal changes the nature of the token. >> "due to some parser quirks they may lead to syntax errors" > > Right. Where those "quirks" represent conforming with the syntax rules as specified for the language that is being parsed. >> "do not use the above mentioned syntax shortcut and to use full >> syntax with quotes around each property name" > > Right. Where what you are describing as "the full syntax" is nothing but a sub-set of the syntax for object literals. >> 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 That would depend on what you mean by "learn the language". It is not a document that will teach anyone how to program with javascript. It is, however, the optimum document for understanding precisely how the various constructs used in javascript behave, being the specification for that behaviour. Consider the issue in your OP; you can (and you did) speculate about "broken switch-case" or "not a constructor but a block of statements", but an examination of the spec shows that the observed behaviour corresponds with the specified behaviour, and explains the specified behaviour. Thus avoiding much time wasted in considering irrelevant alternatives. > because its main purpose is not to explain the language, but > to describe the internal algorithms ECMA 262 is very explicit about stating that implementations are not required to implement any of its algorithms, rather they are required to behave precisely as if they did implement those algorithms. That is, it is a specification of required behaviour, not a source of instructions on how that behaviour must be achieved. > so make it possible to > write compliant engines for other than Netscape browsers. The method the specification adopts in order to facilitate the writing of compliant engines is to fully define the behaviour expected of such an engine. The effect of that is to make the document _the_ source for a full definition of the behaviour expected of an ECMAScript implementation. Another obvious function for the specification is to provide a vocabulary of technical terms for use when talking about javascript that have the advantage of being objectively defined. Thus, people can talk about Activation objects, execution contexts, etc, and everyone else can know what they are talking about with sufficient precision to allow the truth of such statements to be objectively examined. Of course, you do not like that latter consideration at all because little exposes inconsistent/incomplete explanations faster than the use of precise and objectively defined terminology. You would prefer everything to be expressed in a form that represents nothing more certain than the sort of vague mush that is the usual product of your thought process. > The difference is as between say a Perl user reference and > comments for C libraries used for Perl processor. Does Perl not have a specification, or do you believe that the people who really know Perl well do not know/understand that specification? > As the result some regulars know some really refined > internal mechanics, some of which even never did into > any actual implementation, The question is not whether an implementation implements any particular algorithm or not, but rather whether it behaves as if it implemented those algorithms. Failing to behave as if it implements all the algorithms while claiming to be an ECMA 262 conforming implementation constitutes a language bug. Unsurprisingly, it is necessary to know (or, at minimum, refer to) those algorithms in order to be in a position to declare any particular observed behaviour correct or incorrect. > yet having troubles to get some obviousnesses. Obviousness is, pretty much by definition, a subjective judgment. You always have tended to see certain things as obvious where others perceive then as anything but, and not to see at all some things that others perceive as obvious. > In the particular and most importantly they are normally having > big time troubles to distinguish *language* features and > *underlaying C-based engine* features Underlying implementation details are almost completely irrelevant to any discussion of javascript. We have a language that is designed to be independent of everything but its host API/Object Model, and a language that can be implemented in pretty much any other language. There is certainly little point in considering some "C-based engine" when there are so many implementations that are not "C-based" such as Rhino being an implementation in Java, reference implantations being created in ML and even javascript based implementations such as Narcissus. It is actually very unlikely that the approaches taken towards an implementation in C (or C++) is even applicable in any alternative implementation language. If anything, it strikes me that it is you who tends to fixate on irrelevant details of particular implementations. > and consequently having troubles to separate properly > tokenizing, parsing and execution stages, What evidence do you base that assertion on? > 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: Because it proved so convincing the last half dozen times? > parsed by the rule of an identifier !== to > be an identifier. For someone who comments of other's failure to "separate properly tokenizing, parsing and execution stages" it is ironic that you talk of "parsed by the rule of an identifier" when Identifiers are tokens (see section 7.5 "Tokens"), and so the product of tokenising not parsing. > In object constructor You mean object literal? > all key values are string literals, No they are not. They are Identifiers, string literal or numeric literals. > explicitly or implicitly quoted. There is no need for 'implicit quoting', and if it did exist there would be may constructs that could be allowed in the context of the property name part of an object literal (because they would not be ambiguous) but are not allowed in that context. > Again, we are taking about > JavaScript, so about the execution stage. No, we are talking about the difference between constructs that result in syntax errors and constructs that do not, so the pertinent stage is the parsing stage. Observe, for example, that:- var x; if(false){ x = { #:1 }; } - is still a syntax error even though the code for the object literal cannot ever be executed. > What and how exactly C program treats the source code stream is > irrelevant here Any C program is irrelevant (especially given that there is no need for the parser to be a C program, and plenty of examples that are not). On the other hand, the specification makes statements about how any javascript implementation is supposed to behave in tokenising and parsing in addition to execution. > 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" :) The "trouble" here is a consequence of not knowing the syntax for the language, and nothing else. Syntax errors are a likely consequence of not knowing the syntax of the language you are using, and such errors can occur in any context. Attempting to address that situation by requiring that the property name parts of object literal always take the form of string literals will not address the syntax errors the ignorant author will inevitably create elsewhere. >> > Simple and clear. > > Indeed You are agreeing with yourself again. >> 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, No they are not. > explicitly or implicitly quoted. Again, we are taking > about JavaScript, so about the execution stage. Despite the fact that the code for an object literal does not necessarily ever get executed and that syntax errors happen to the exclusion of execution? > What and how exactly C > program treats the source code stream is irrelevant here And doubly so for implementations in Java, ML or javascript. > yet might be > interesting in other circumstances. > >> "the quotes will be added automatically" > > See right above. See what "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. When you make up your own "parser rules" they do not then constitute a weakness in �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. You don't say. > "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. What you are saying is that not knowing the syntax rules leaves you not knowing the syntax rules, and so wasting your time as a consequence. You may notice how quickly it is for someone who does know the syntax rules to spot the issue and correctly attribute it, despite their possibly being familiar with the specification. > 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. No, I only need to distinguish between Identifiers as the yare defined in javascript and all the possible other interpretations of the term that may be employed in other contexts. For which I need nothing more than a precise definition of what an Identifier is in relation to javascript, as provided by the specification. >>> 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*. The place where these terms are used "in the *language*", as you put it, is in the specification for the language. > Can you make an effort and to get > out from the irrelevant lower level matters? I already have little interest in "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. True, but then your point would be? > 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. There is a delusion here, but it is in your perception. The parsing of the language is defined in the specification, and is relevant to the issues here, but at no point has anything said here by anyone but you involved "C/C++ parser rules". Javascript's parsing rules are independent of any particular language used to implement javascript. Ricahrd.
From: John G Harris on 2 Nov 2009 14:56 On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote: <snip> >The identifier foo identifies a variable foo in the context of Global >or function scope. In a 'with' statement it identifies a property if the 'with' object has a property with that name. >In an implicit object constructor if used in the >position of the property name it identifies ... <snip> >Another option - other than claiming your quoted statement be a lore >from the Alpha Centauri programming school :) - is to stop writing >"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary >capitalization and proper reference so then make it clear that you are >not talking about a programming entity but about a charcode sequence >defined by such and such formal criteria. Then: You need glasses. I never *started* using 'identifier' when I meant 'Identifier'. When did source files stop containing 'programming entities' ? <snip> >1) What is the difference between a Harris' "parsing stage ECMA 262 >3rd.ed. Identifier" on and an "identifier" in the casual programming >sense in the program itself. <snip> We've been trying to work out what you mean when you write identifier. You seem to change your meaning every other paragraph. John -- John Harris
From: VK on 4 Nov 2009 13:27 On Nov 2, 10:56 pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: > On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote: > > <snip> > > >The identifier foo identifies a variable foo in the context of Global > >or function scope. > > In a 'with' statement it identifies a property if the 'with' object has > a property with that name. Let's not talk about all things at once. Right now we are looking at an object constructor literal. > >In an implicit object constructor if used in the > >position of the property name it identifies > > ... > > <snip> So I understand that besides the suggested definition extension above the first definition is what you were trying to say. Well, I only can repeat that "this is an extremely weird approach of course but at least it has some sense within the human programming science". I still do not understand why you are considering this approach - not used anywhere outside this group and actually nowhere outside of this thread - as something definitely and only right one. > >Another option - other than claiming your quoted statement be a lore > >from the Alpha Centauri programming school :) - is to stop writing > >"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary > >capitalization and proper reference so then make it clear that you are > >not talking about a programming entity but about a charcode sequence > >defined by such and such formal criteria. Then: > > You need glasses. I never *started* using 'identifier' when I meant > 'Identifier'. Possibly not you, sorry then. It was a bounch of exited posts in here with "identifier", "Identifier" mixed in all different ways. > When did source files stop containing 'programming entities' ? at the moment it's going through the parser. > <snip>>1) What is the difference between a Harris' "parsing stage ECMA 262 > >3rd.ed. Identifier" on and an "identifier" in the casual programming > >sense in the program itself. > > <snip> > > We've been trying to work out what you mean when you write identifier. > You seem to change your meaning every other paragraph. That's rather stupid to claim. All the way though I was very explicit by what does "identifier" mean in the programming (not in some "VK's thesaurus" or so): with 3rd source definitions, with samples of identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and execution stage. You just need to follow the thread.
From: John G Harris on 5 Nov 2009 10:34
On Wed, 4 Nov 2009 at 10:27:07, in comp.lang.javascript, VK wrote: >On Nov 2, 10:56�pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: >> On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote: >> >> � <snip> >> >> >The identifier foo identifies a variable foo in the context of Global >> >or function scope. >> >> In a 'with' statement it identifies a property if the 'with' object has >> a property with that name. > >Let's not talk about all things at once. Right now we are looking at >an object constructor literal. But you're the one who is talking about identifiers naming variables. I just added another case, where it names a property. >> >In an implicit object constructor if used in the >> >position of the property name it identifies <snip> >All the way though I was very explicit >by what does "identifier" mean in the programming (not in some "VK's >thesaurus" or so): with 3rd source definitions, with samples of >identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and >execution stage. You just need to follow the thread. In all the mainstream languages 'identifier' means any sequence of characters in a source file that matches the collection of syntax rules named either 'Identifier' or 'identifier'. In database technology 'identifier' has a more specific and technical meaning. John -- John Harris |