Re: Implicit object constructor misinterpretation
- From: "Richard Cornford" <Richard@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 2 Nov 2009 00:15:24 -0000
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.
.
- Prev by Date: Re: Implicit object constructor misinterpretation
- Next by Date: Re: Problem with getSelection() in iframe in chrome
- Previous by thread: Re: Implicit object constructor misinterpretation
- Next by thread: Variable Instantiation
- Index(es):
Relevant Pages
|
