Implicit object constructor misinterpretation

[VK]

We may use string literals as keys. The difference between
 foo: 42
and
 "foo": 42
isn't that we quote anything, but that one is an identifier and the other
is a string literal. Completely different syntactic categories, both
valid at this particular point of an object initializer.

I think I am starting to see the mistake making by Richard and by you:
or maybe and very probably not a mistake but some profound difference
in the applied logic between of us, because - I agree in advance - my
logic is too "special".
If unquoted key is interpreted as identifier - in the identifier sense
I am using for more than 10 years and to late to change I'm afraid :
( - then in case like

var a = 'foo';
var obj1 = {a : 'bar'}
var obj2 = {'a': 'bar'}

obj1 and obj2 have to have different properties: 'foo' in the first
case, 'a' in the second. In the reality both of them are having the
same property 'a'

I am really sorry but an "identifier" that is not get identified is
not an identifier, and the whole ECMA 262 wisdom may not override it
in my (stupid, stubborning, whatever) head.

 

[Lasse Reichstein Nielsen]

I think I am starting to see the mistake making by Richard and by you:
or maybe and very probably not a mistake but some profound difference
in the applied logic between of us, because - I agree in advance - my
logic is too "special".
If unquoted key is interpreted as identifier - in the identifier sense
I am using for more than 10 years and to late to change I'm afraid :
( - then in case like

var a = 'foo';
var obj1 = {a : 'bar'}
var obj2 = {'a': 'bar'}

obj1 and obj2 have to have different properties: 'foo' in the first
case, 'a' in the second. In the reality both of them are having the
same property 'a'

Here you fail to distinguish between an identifier and a variable. In
ECMAScript syntax, an Identifier is a syntactic category. I.e., it
denotes a sequence of characters. It is used in several different
places where something can be given a name: A variable name, an object
property name, a function name. The identifier specifies a name. It
is not the thing it names.

In your example, the identifier "a" is used twice: Once to identify a
variable, and once to identify an object property. The two are not
related. The use as a property name does not refer to the variable,
nor is it evaluated to the variable's value.

Consider this example:
function a() {
var a = {a: 42};
return a.a;
}
The identifier "a" is used five times, three times to name the
function, the variable and the object property, and two times to
reference the variable and the object property.

I am really sorry but an "identifier" that is not get identified is
not an identifier, and the whole ECMA 262 wisdom may not override it
in my (stupid, stubborning, whatever) head.

In the case:

var a = "foo";
function() {
var a = "bar";
}

would you expect the variable inside the function to be called "foo"?
It's called "a" too, because a name *in a declaration* is not interpreted.
It's the same for object initializers: They contain declarations of
properties. The names are not interpreted, so:

var a = "foo";
var b = {a : 42};

declares a property named "a" on an object, not "foo".

/L

 

[VK]

Consider this example:
 function a() {
   var a = {a: 42};
   return a.a;
 }
The identifier "a" is used five times, three times to name the
function, the variable and the object property, and two times to
reference the variable and the object property.

"VK's universe": identifier "a" is used two times: to name a function
and to name function-level variable. As these entities are in
different scopes we have no identifiers conflict. The third use is
object property name with is implicit string value and not a relevant
part of the test case.
To have an identifiers conflict we obviously need to use them in the
same scope, so to illustrate what was intended to be illustrated we
need to place identifiers in the same scope:
function a() {a=1;} // 1
function a() {a=2;} // 2
window.alert(a.toString()); // the 2dn one
or
a = 1;
a = (a == a + a - a);
window.alert(a); // true

In the case:

 var a = "foo";
 function() {
   var a = "bar";
 }

would you expect the variable inside the function to be called "foo"?

"VK's universe": Of course not because the identified variables are in
different scopes: the outer one (Global if this is the whole code of
the script as posted) with value "foo" and the inner one (function
level).

It's called "a" too, because a name *in a declaration* is not interpreted..
It's the same for object initializers: They contain declarations of
properties. The names are not interpreted, so:

 var a = "foo";
 var b = {a : 42};

declares a property named "a" on an object, not "foo".

"VK's universe": because object property name is a string one may skip
quotes as they are implied. But in this case it has to conform with
JavaScript naming rules for identifiers because the parser is
optimized for the quickest code source parsing so it will not bother
with each and every non-quoted literal context: it just checks that
each non-quoted literal is either a number, or one of reserved values
like true or null, or a valid JavaScript variable name. If neither it
drops the parsing so do no waste the time.

P.S. I seem to feel what you really tried to say by your samples.
Something like "identifier <a> identifying property name "a" or
something like that and I do agree that such interpretation is
possible - but IMHO such level of abstraction is way too high to be
practical.

 

[VK]

"VK's universe": because object property name is a string one may skip

quotes as they are implied. But in this case it has to conform with
JavaScript naming rules for identifiers because the parser is
optimized for the quickest code source parsing so it will not bother
with each and every non-quoted literal context: it just checks that
each non-quoted literal is either a number, or one of reserved values
like true or null, or a valid JavaScript variable name. If neither it
drops the parsing so do no waste the time.

And about the Gecko engine the answer from mozilla.dev.tech.js-engine
just reminded me the old discussion here about the SpiderMonkey's
particular treatment of reserved words: the parser keeps the list not
all reserved words but only ones actually being in use by the current
machine, so for Gecko browsers it is fully OK like:
var class = 'foobar';
window.alert(class); // 'foobar'

 

[VK]

To be the most precise about the weird VK's universe which is can/must
be considered totally twisted yet is immutable by design:

//////////////////////
// explanation starts

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. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

At
http://groups.google.com/group/comp.lang.javascript/msg/715f984ce356c5ae
Richard Cornford shoots the breeze to the full extend of his
definitely remarkable language knowledge and writing skills but he
lost me somewhere at the first third of his post - definitely because
of my IQ level problems. I just managed to get that there are
identifying identifiers like in var a = true; and identifiers that do
not identify anything but still identifiers; I also started to get
that there is some mystical yet deeply profound difference between foo
and foo properties created like this:
var obj = {'foo' : 'bar'}
or like that:
var obj = {foo : 'bar'}
but at this point my on-board computer got overheated and so my mind
disconnected.

I seem to understand - after a few beers - that implicitly quoted foo
in
var obj = {foo : 'bar'}
may be also interpreted as an identifier that doesn't identify
anything. After one more beer I even can imagine that such "non-
identifying identifier" still identifies something: namely string
literal value foo (charcode sequence \u0066\u006F\u006F), in a round
around way like identifier true identifies boolean value true. This
way - after having finished the last beer - I may get ready to
introduce new type of identifiers in JavaScript where each one
identifies a single string literal with charcode sequence equal to
one's of identifier if the latter is taken as a string.
It is possible but I don't see a single reason in syllogistic
exercises of the kind unless trying to occupy one's bored mind: or
unless desperately trying to put some sense into yet another ECMA 262
3rd.ed. verbal fart. IMHO.

P.S. There are two distinct stages for a program: the parsing stage
(with possible syntax errors) and the execution stage (with possible
runtime errors). Respectively there can be different identifiers for
each stage: not those philosophic "non-identifying identifiers" but
normal identifiers for preprocessor variables and identifiers for
program variables. For the moment unfortunately only JScript provides
access to the processing stage, so one needs IE5 or higher to see the
preprocessing results, on other UAs it will be the else-branch. Also
it is a demo code so unnecessarily complicated to involve the needed
instructions:

function demo() {
/*@cc_on
@*/
/*@set @a = 1
@set @b = 2
@if (@_mac)
var obj = {@a : true}
@elif (@_win32)
var obj = {@b : true}
@else @*/
var obj = {3 : true}
/*@end
@*/
for (var p in obj) {
window.
alert('obj[\''+p+'\']='+obj[p]);
}
}

P.P.S. And the "non-identifying identifiers" for property names is
better keep for mind games or best of all throw away. IMHO.

 

[John G Harris]

On Sat, 24 Oct 2009 at 10:12:29, in comp.lang.javascript, VK wrote:

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.

<snip>

You haven't seen the problem, have you. You can parse this :

var a = { b: 27 };
with (a) b;

because you know for sure what I meant when I wrote it.

With your preferred rule you can't parse this :

var a = { return: 27 };
with (a) return;

because you don't know what I meant when I wrote it.

John

PS This is going to cause trouble in ES 5 non-strict; something else for
Crockford to moan about.

 

[Thomas 'PointedEars' Lahn]

To be the most precise about the weird VK's universe which is can/must
be considered totally twisted yet is immutable by design:

Often Wrong, will you *please* spare us your fairytale "explanations" from
your apparently parallel universe? Instead, tell us in *simple* words what
you have understood (please accept the fact that you are yet not capable of
more complex wording in English without posting gibberish). Then you may be
either confirmed or disproved without too much effort.

[...]
I seem to understand - after a few beers - that implicitly quoted foo
in
var obj = {foo : 'bar'}
may be also interpreted as an identifier that doesn't identify
anything.

Will you *please* drop that fantasy of yours? Nothing is implicitly quoted
here! `foo' is called an identifier because it must be produced by the
/Identifier/ production. That production requires that a sequence of
characters conforms to some rules (e.g., it must start with a letter or
underscore), and it must not be a keyword. `default' is a keyword because
it can be produced by the /Keyword/ production.

The part left-hand side of the `:' is supposed to become the name of the
property. If, and only if, the name of the desired property cannot be
produced by the /Identifier/ production (such as with `default'), there are
two possibilities left to make the expression into a syntactically valid
/ObjectLiteral/: It can either be produced by the /StringLiteral/ production
or the /NumericLiteral/ production.

And then, *regardless* of how the name of the property was defined, it is
stored and handled as a string of characters.

Nothing more, nothing less.

After one more beer [...]

Don't drink and derive!


PointedEars

 

[VK]

here!  `foo' is called an identifier because it must be produced by the
/Identifier/ production.

Almost perfect, one half in there already! It is no way an identifier,
it is a string *parsed by the rules of an identifier* to speed up the
parsing process, otherwise the parser would need to use a bunch of
positive and negative look-backs to interpret the context properly.
Instead it goes by much more plain but effective way: "no quotes - you
are identifier for now, later the program will decide if it's possible
or not" (plus some icing on the cake with = signs account so do not
make the parser overly stupid).
Now you need to make one last step to recognize that something treated
by rules of another entity doesn't become that entity unless it also
accomplish the functions of the said entity. If the boss treats
someone as a shit it doesn't automatically mean then that someone is a
sh** unless actually acting as a sh**. If someone treats me as a king
I am still not a king unless ruling a kingdom, etc. Wiki definition is
no way normative but is a result of some consensus using authoritative
sources:
http://en.wikipedia.org/wiki/Identifier#Identifiers_in_computer_languages
"In computer languages, identifiers are tokens (also called symbols)
which name language entities."
Unless we are taking my humorous suggestion of foo identifier
identifying \u0066\u006F\u006F (="foo") string literal, unless that it
is of course not an identifier. After some thinking over it you'll
make the last step and will be in here:

//////////////////////
// explanation starts

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. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

 

[Thomas 'PointedEars' Lahn]

Almost perfect, one half in there already!

You must be kidding.

It is no way an identifier, it is a string *parsed by the rules of an
identifier*

If by "string" you mean "sequence of characters", then you would be correct.
However, it would be quibbling over words then (your wording would be
precisely my meaning and that of the Specification), because the whole
source code is necessarily a sequence of characters. And quibbling over
words does not become someone like you who posts gibberish regularly.

[more VK nonsense]

I do not know what point you were trying to make there, but, as usual, you
failed badly in doing that.


PointedEars

 

[VK]

You must be kidding.

Deadly serious. You just keep thinking over it - the main part of the
path is already done. btw somehow I overlooked the answer of Brendan
Eich to my post at mozilla.dev.tech.js-engine Who doesn't have this
group and doesn't want to use GG I am copying it here:

Brendan Eich wrote:
Not a bug, yes a convenience, and proper implementation of ES5 (after
ES3.1 and ES4, which both allowed reserved words to be used in
property-name contexts). Also a proper extension to ES3, which allows
such syntactic extensions (see chapter 16).

IE has yet to ship the ES5 JScript implementation I've seen demo'ed at
Ecma TC39 meetings.

So it is as as earlier explained: property names are strings,
explicitly quoted or implicitly quoted. Brendan Eich refers to ECMA
262 3rd.ed. Chapter 16 "Errors"
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
and logically I do agree with him: if a non-quoted character sequence
in this position is guaranteed to be quoted (treated as a string
literal on the execution stage) then it is really not a parser's
monkey business to check its language naming conformance or check it
against a reserved words table.
Any way coming back to the same:

//////////////////////
// explanation starts

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. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

 

[Thomas 'PointedEars' Lahn]

VK wrote:

When will you ever learn?

You must be kidding.

Deadly serious. You just keep thinking over it - the main part of the
path is already done. [...]

Idiot.


PointedEars

 

[Lasse Reichstein Nielsen]

//////////////////////
// explanation starts

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.

That's still wrong.
It's not a matter of omitting quotes, or quotes being automatically
inserted.
It's three different ways to specify the name of a property:
- A string literal
- A number literal
- An identifier
Each is converted to a string (yes, also the string literal - there
is a difference between a string literal and a string value!).

To show, once again, that it's not just a matter of omitting quotes,
consider this object initializer:
var obj = { "3.0" : 42, 3.0 : 37 };

Guess what is alerted by:
alert([obj[3], obj[3.0], obj["3"], obj["3.0"]]);
(It's "37,37,37,42", if there was any doubt)

/L

 

[VK]

To show, once again, that it's not just a matter of omitting quotes,
consider this object initializer:
 var obj = { "3.0" : 42, 3.0 : 37 };

Guess what is alerted by:
  alert([obj[3], obj[3.0], obj["3"], obj["3.0"]]);
(It's "37,37,37,42", if there was any doubt)

I am not forcing anyone to "my universe", just explaining why am I
comfortable in there. If one decides to make the interpreter dizzy or
to conduct a "sh** check" on it rather than writing reliable programs
than ECMA's Book of Source (Chapter 6) provide a lot of "useful"
hints:

var key = '';

var obj = {
// 1
'3.0' : 0,
'300000000000000000003' : 0,
'3000000000000000000003' : 0,
// 2
3.0 : 0,
300000000000000000003 : 0,
3000000000000000000003 : 0
};

for (key in obj) {window.alert(key);}

// 1
verbatim
verbatim
verbatim
// 2
3
30000000000000000000
3e+21

From the deranged perspective of my alternative universe I see no
connection though of parsing rules for number literals with the topic
of question which takes case much later. I am wrong, of course.

//////////////////////
// explanation starts

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. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

 

[VK]

Did you hear about
http://en.wikipedia.org/wiki/Gödel's_incompleteness_theorems#First_incompleteness_theorem
? IMHO you are trying to make in this little topic the same what Dr.
is trying with calendars: prove it wrong by having built both
consistent and complete description of something. I don't - plus I
definitely know that there are not any identifiers in here, I like the
semantics too much to let them into.
My explanation remains unchanged. Maybe(?) it is not complete but it
is consistent for any sane practical use. At the beginning I also
though to add "to syntax errors or to unforeseen results" with
var obj = {
300000000000000000003 : 0,
3000000000000000000003 : 0
};
but rightly didn't do it because it may give an idea that such coding
can be met somewhere or even possible while the task is to lock such
path for thinking completely. "syntax error" sounds short and serious,
verbosed explanations of possible problems spoil the effect. It's just
like "don't go on the red or may be killed". There is no need to spell
all possible vehicles causing the death and all possible deadly
options.

//////////////////////
// explanation starts

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. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

 

[Thomas 'PointedEars' Lahn]

To show, once again, that it's not just a matter of omitting quotes,
consider this object initializer:
var obj = { "3.0" : 42, 3.0 : 37 };

Guess what is alerted by:
alert([obj[3], obj[3.0], obj["3"], obj["3.0"]]);
(It's "37,37,37,42", if there was any doubt)

I am not forcing anyone to "my universe", just explaining why am I
comfortable in there.

It is very easy to explain why you *feel* comfortable in your fantasy world.
The cause is what can rightly be called the Matrix phenomenon now: Ignorance
is bliss; but only to the ignorant. If you decide to ignore the facts
presented to you, if you decide to deceive yourself making up elaborate
stories instead, then it is virtually impossible for anyone else to convince
you that you are mistaken.

However, as a matter of fact, those who defy reality will ultimately cause
their own doom, and the problem will solve itself in time. So keep on
taking your blue pills, but please: stop expecting reasonable people to jump
off the cliff with you.

If one decides to make the interpreter dizzy

An interpreter (that is not relevant here as the source code is compiled
first, so the tokenizer must be part of the compiler instead) cannot be made
dizzy in any case. It is an implementation of relentless mechanical
(binary) logic, operating upon defined rules.

or to conduct a "sh** check"

A *what*?

on it rather than writing reliable programs

In order to write reliable programs one needs to understand the rules of the
used programming languages first. You have sufficiently demonstrated that
you are incapable of that.

than ECMA's Book of Source (Chapter 6)

There is no such thing, Often Wrong. This is not about religion; it is not
about belief, but about facts; specified, implemented, evident facts.

provide a lot of "useful" hints: [...]

No, your postings so far range only from being a nuisance to an annoyance;
they must be incredibly confusing to newcomers. That is probably the only
reason why I do not have you killfiled yet: Someone has to deal with your
naive, foolish presumptuousness, disprove your fairytale stories, correct
your outright lies; in short: someone has to put you in your place.

If only you stopped doing that ...


PointedEars

 

[RobG]

Yes I did.


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.

 

[optimistx]

As you know, I
consider that mental illness on your part is the theory that best fits
the evidence of your actions.

Interesting that you say so.

 

[Thomas 'PointedEars' Lahn]

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

 

[VK]

No, your postings so far range only from being a nuisance to an annoyance;
they must be incredibly confusing to newcomers.  That is probably the only
reason why I do not have you killfiled yet: Someone has to deal with your
naive, foolish presumptuousness, disprove your fairytale stories, correct
your outright lies; in short: someone has to put you in your place.

You guys are such boring dicks so often... In my simple instruction it
is stated that in object constructors property names are not evaluated
and treated as strings even if quotes are omitted which is allowed for
simplicity; but if quotes are omitted, some troubles are possible on
the parsing stage so better to use them. Simple and clear. Now look at
all this squealing and whining produced just because VK said it, not
some of His Majesties. By taking all verbal flood out from either
Cornford's or yours we are coming to:
1) unquoted property names being processed on the parsing stage by
Identifier rules if correspond to the formal Identifier criteria
(start with _ $ A-z or \XXXX char). They are not identifiers and they
are not becoming identifiers out of being processed by this rules.
2) At run-time unquoted keys are acting as string literals, even if
not quoted - so "auto-quoted" as I said but you don't need to use this
term if it is such an irritation to you.
Other words you just spent 10 times more words to say what I said.
Plus in the best traditions of clj you dug out a bunch of crazy usage
cases (exploring IEEE-754 numeral literals parsing specifics) to prove
hell knows what. That the advise to always use quotes is wrong? It
failed then. That keys do not act at runtime as implicitly or
explicitly quoted string literals? It failed than. I really didn't get
what that verbal diarrhea was about, except maybe to make everyone to
believe that JavaScript is a hugely enormously complicated language
which it is not at all. It just like with the prototype inheritance
which is simple as a moo cow yet never was normally explained here
over all these years: because every time the explanation gets trashed
by occasional cases, crazy code twists, counterexamples etc up to the
point that readers get impression than it would be easier to emulate
OOP in AutoLISP rather than ever touch that crazy JavaScript.

With all my due respect.

 

[VK]

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.

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"

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?


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.

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.