Implicit object constructor misinterpretation

[VK]

Just nailed down a spurious bug from a 3rd party code which seems to
be in unexpected continuation of "Little Help with JavaScript" side
discussion and Mr.Cornford comments:
http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265cb5

The minified test case:

var test = {
op1 : false,
op2 : false,
default: false
}

window.alert(test.default);

Leads to the syntax error on all test set browsers but Firefox where
it expectedly (? unexpectedly ?) reports that test.default = false

The others (IE, Safari, Chrome, Opera) do consider such code as a
broken switch-case construction so reporting the missing switch
clause. By taking default key into quotes such reading goes away:

var test = {
op1 : false,
op2 : false,
'default': false
}

window.alert(test.default); // false

I honestly don't give a damn what ECMA says on it, it sucks even
carved somewhere on a stone. With this and the preceding label vs key
issue the safe coding policy will be changed: it will be required in
the office and from subcontractors to use explicit quoting of object
key values and do not ever relay on the implicit one. The group
readers may or may not account this coding advise.

 

[Thomas 'PointedEars' Lahn]

Just nailed down a spurious bug from a 3rd party code which seems to
be in unexpected continuation of "Little Help with JavaScript" side
discussion and Mr.Cornford comments:
http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265cb5

The minified test case:

var test = {
op1 : false,
op2 : false,
default: false
}

window.alert(test.default);

Leads to the syntax error on all test set browsers but Firefox where
it expectedly (? unexpectedly ?) reports that test.default = false

Whereas the error is not caused by the window.alert(...) call, of course.

The others (IE, Safari, Chrome, Opera) do consider such code as a
broken switch-case construction so reporting the missing switch
clause. By taking default key into quotes such reading goes away:

var test = {
op1 : false,
op2 : false,
'default': false
}

window.alert(test.default); // false

I honestly don't give a damn what ECMA says on it,

And exactly that is the problem with you. You rather make up fancy stories
(here: about switch-case misrecognition) instead.

`default' is a keyword; it may not be used as identifier in an ECMAScript-3
compliant /Program/ (ES3F, 7.5.2). And when not a /StringLiteral/ or a
/NumericLiteral/, the name part in an /ObjectLiteral/ must be an
/Identifier/ (ES3F, 11.1.5).

Mozilla.org JavaScript's deviation is either a bug, an implementation of
behavior specified by ES5 (FD), or an implementation of ES3F's Conformance
section where it says:

| A conforming implementation of ECMAScript is permitted to support program
| and regular expression syntax not described in this specification.


PointedEars

 

[Evertjan.]

VK wrote on 24 okt 2009 in comp.lang.javascript:

Just nailed down a spurious bug from a 3rd party code which seems to
be in unexpected continuation of "Little Help with JavaScript" side
discussion and Mr.Cornford comments:
http://groups.google.com/group/comp.lang.javascript/msg/ff0101e295265c
b5

The minified test case:

var test = {
op1 : false,
op2 : false,
default: false
}

window.alert(test.default);

Leads to the syntax error on all test set browsers but Firefox where
it expectedly (? unexpectedly ?) reports that test.default = false

The others (IE, Safari, Chrome, Opera) do consider such code as a
broken switch-case construction so reporting the missing switch
clause. By taking default key into quotes such reading goes away:

var test = {
op1 : false,
op2 : false,
'default': false
}

window.alert(test.default); // false

I honestly don't give a damn what ECMA says on it, it sucks even
carved somewhere on a stone. With this and the preceding label vs key
issue the safe coding policy will be changed: it will be required in
the office and from subcontractors to use explicit quoting of object
key values and do not ever relay on the implicit one. The group
readers may or may not account this coding advise.

"> Just nailed down ... " ??

The writer of Jason knew this already,
[that keys should but do not always condone reserved words]
it was the reason that he required all keys to be quoted.

 

[VK]

Whereas the error is not caused by the window.alert(...) call, of course.

`default' is a keyword; it may not be used as identifier in an ECMAScript-3
compliant /Program/ (ES3F, 7.5.2).  And when not a /StringLiteral/ or a
/NumericLiteral/, the name part in an /ObjectLiteral/ must be an
/Identifier/ (ES3F, 11.1.5).

Do you understand the difference between literal values and string
values? One cannot have
var class = 'foo';
but it is perfectly OK to have
myObject['class'] = 'foo';

'default' in the quoted context is a string to use as key name, no way
it can be treated as a literal. JavaScript provides Perl-like shortcut
syntax with key string quotes omitted to save "poor programmer's
fingers" and to improve(?) code readability - and respectively
automatically added by the parser. For me it is obvious that all
parsers but Fx's are fubar on at by treating a shortcut syntax of a
key string as a literal.
Just another prove of my old credo: never economize on keystrokes and
don't let other do it as well, this is cheapest resource to spend.

 

[VK]

(Incidentally, the "office" delusion is interesting, as you are such an
appalling programmer that it is literally increasable to suggest that
you have any colleagues that are capable of programming at all and that
you maintain employment in such an environment.)

Surprisingly for you I do, because I am doing what my clients do need
and I am heavily indifferent in this aspect on what some c.l.j.
regulars want to see. Sometimes I am getting really strange situations
caused by some obscure specs or implementation quirks and then I let
guys like you to get their $40-$60/hour geek plus free coffee and
doughnuts - but most of the time they are not needed so it is times
cheaper to keep a verified freelancers' list rather than to keep it on
salary + benefits

 

[Thomas 'PointedEars' Lahn]

`default' is a keyword; it may not be used as identifier in an
ECMAScript-3 compliant /Program/ (ES3F, 7.5.2). And when not a
/StringLiteral/ or a /NumericLiteral/, the name part in an
/ObjectLiteral/ must be an /Identifier/ (ES3F, 11.1.5).

Do you understand the difference between literal values and string
values? One cannot have
var class = 'foo';
but it is perfectly OK to have
myObject['class'] = 'foo';

Red herring. We are not talking about variable declarations or property
accessors here; we are talking about Object initializers.

'default' in the quoted context is a string to use as key name,

Often Wrong, there are no keys. (_Property names_ are always strings, but
that does not matter here.)

There is an /Expression/ here that can only be produced by the
/ObjectInitializer/ production. And the grammar for that
/ObjectInitializer/ requires that the part before the `:' (which I called
"name part") be either an /Identifier/, a /StringLiteral/, or a
/NumericLiteral/. `default' is neither -- so syntactically invalid --.
As a result, e.g. my IE, too, reports what Richard already said.

Your placing either <'> or <"> around `default' makes it being producable by
the /StringLiteral/ production again -- so syntactically valid.

It is simple mechanical logic that is at work here, and despite two detailed
explanations you are still incapable to get it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

`default' is a keyword; it may not be used as identifier in an
ECMAScript-3 compliant /Program/ (ES3F, 7.5.2). And when not a
/StringLiteral/ or a /NumericLiteral/, the name part in an
/ObjectLiteral/ must be an /Identifier/ (ES3F, 11.1.5).

Do you understand the difference between literal values and string
values? One cannot have
var class = 'foo';
but it is perfectly OK to have
myObject['class'] = 'foo';

Red herring. We are not talking about variable declarations or property
accessors here; we are talking about Object initializers.

'default' in the quoted context is a string to use as key name,

Often Wrong, there are no keys. (_Property names_ are always strings, but
that does not matter here.)

There is an /Expression/ here that can only be produced by the
/ObjectLiteral/ production. And the grammar for that
/ObjectLiteral/ requires that the part before the `:' (which I called
"name part") be either an /Identifier/, a /StringLiteral/, or a
/NumericLiteral/.

`default' is neither -- so syntactically invalid. As a result, e.g. my IE,
too, reports what Richard already said.

Your placing either <'> or <"> around `default' makes it being producable by
the /StringLiteral/ production again -- so syntactically valid.

It is simple, relentless mechanical logic that is at work here, and despite
two detailed explanations you are still incapable to get it.


PointedEars

 

[Evertjan.]

Richard Cornford wrote on 24 okt 2009 in comp.lang.javascript:

The writer of Jason knew this already,
[that keys should but do not always condone reserved words]
it was the reason that he required all keys to be quoted.

But the need in JSON follows from its use with unknowable data sources
where the character sequences that will end up in the keys are
unpredictable. For a programmer writing an object literal the character
sequence that will be the key is known at the point of writing it, and

True, but the reserved word list is crossbrowserly perhaps knowable,
but illogical.

so knowing the syntax rules for the object literal construct allows them
to either see when the names they want to use need special handling or
to question their choice of names. Blanket rules are not necessary in
that context, and their application risks the "programmers" being drawn
into a world of chanting sequences of mystical incantations in place of
understanding what they are doing.

It is interesting to note that JSON not only requires that all the keys
be quoted, but that they be quoted with the double quote character (as
opposed to the apostrophe). It is easy to see how such simplifications
of format ease the string-based processing of the data.

Perhaps ours is not to reason why [cf Alfred Lord Tennyson],
but I wrote it to show the reasoning,
not as a general advice to be followed up.

A parallel is the [ugly?] habit to [] fieldnames in sql strings,
also to preclude possible reserved word errors.

 

[John G Harris]

On Sat, 24 Oct 2009 at 06:56:27, in comp.lang.javascript, VK wrote:

I honestly don't give a damn what ECMA says on it, it sucks even
carved somewhere on a stone.

<snip>

The man who invented the language said it must be like that. Get used to
it.

If you can't, find another language.

John

 

[VK]

Or just learning the syntax rules. VK claims to have been writing
javascript for well in excess of 10 years, so his not already being
familiar with object literal syntax rules is a little incredible (at
least if the initial claim was regarded as credible).

As this being attributed to VK I do answer:
exactly because I am in the commercial programming since late 1996
with two "wars" behind (the Big One of 1996-1998 and the "religious"
one of 2005-2008) many things just don't occur on me because I almost
subconsciously do not do this or do that in only that way. With years
some harmless(?) cargo cult gets accumulated of course: say pre-
declaring all vars over assignment of the supposed type values. At the
same time I am indifferent to any fine-tune language properties if
they lead to a discussion of professional programmers. Because if
there is a discussion then there are at least two possible readings
and it is absolutely non important then what reading is the right one
or what reading is the utterly wrong one, or if both are possible: by
the 1st Murphy's law there already are or soon will be at least two
environments implementing different reading options. This way you code
needs to avoid this particular coding approach ever since and forever.

This is why some c.l.j. regulars are sometimes a shocking experience
to me. One moment they are showing some deepest knowledge of some
really obscure language corners no one else - including engine
implementors - cared about, and the next time showing shocking
naiveness in the most obvious parts of the practical programming. Say
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. 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

Some don't believe I can be in a programming business. Well, sometimes
I am getting - surely very wrong - impression if some posters produced
any commercial code in their lives.

 

[VK]

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. 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, for Eric Lipper porting it to IE. 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.

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.

{
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.

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. 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.

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: 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.

 

[Thomas 'PointedEars' Lahn]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Gregor Kofler]

VK meinte:

[crap snipped]

I honestly don't give a damn what ECMA says on it, it sucks even
carved somewhere on a stone. With this and the preceding label vs key
issue the safe coding policy will be changed: it will be required in
the office and from subcontractors to use explicit quoting of object
key values and do not ever relay on the implicit one. The group
readers may or may not account this coding advise.

For the less perceptive (like you): "default" is a reserved word in JS.

Gregor

 

[VK]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Thomas 'PointedEars' Lahn]

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.

"Effective Monday Nov.26 ... all object key strings to be placed in
single quotes with internal single quotes escaped ... [the punishment
stuff is irrelevant]"
OMG.

Now compare this and the full production description with possible
branching from your post. This is exactly what Occam's Raiser is
about, in my humble interpretation of course

The correct spellings for that methodological principle include "Occam's
razor" and "Ockham's razor" (after William of Ockham [1285/8-1348/9 CE],
English philosopher).

For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine

I pity them already.


PointedEars

 

[VK]

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.

"Effective Monday Nov.26 ... all object key strings to be placed in
single quotes with internal single quotes escaped ... [the punishment
stuff is irrelevant]"

Now compare this and the full production description with possible
branching from your post. This is exactly what Occam's Raiser is
about, in my humble interpretation of course

For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine

 

[VK]

On your record of such promises, I will not be holding my breath.

http://groups.google.com/group/mozilla.dev.tech.js-engine/msg/cb7669ddd693937a

 

[Lasse Reichstein Nielsen]

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.

If interpreted as a program or statement, yes.
In that context, a "{" starts a statement block.

{
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.

Yes, the "{" starts a statement block, and the content is not a
syntactically valid statement block.

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,

Not really. The "{" is in expression context, so it starts an object
literal. The content is a valid object initializer, so yey, it works.
The "automatic quoting" doesn't really exist. It's a completely
different syntactic construct with different rules, that just happens
to look almost the same.

so we may quote the keys,

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.

do not quote them or do quote them zebra-style
or whatever. 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.

It's interpreted as an object key.

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.

No. No quotes are added. The identifier is parsed *as an identifier*.
That identifier is converted to a string value (which takes no
quoting).

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.

Not at all. This is parsed as an object initializer. There is no
automatic quoting, and only string literals and identifiers are valid
keys. Sadly "default" is a keyword, so it is not an identifier, which
makes it a syntax error in the object initializer.

There is no "automatic quoting". There is no "intepretation
decission", only syntactic rules deciding whether a "{" may start
a statement block or an object initializer.

/L