Implicit object constructor misinterpretation

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.

VK wrote:

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

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.



--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

On Sat, 24 Oct 2009 06:56:27 -0700 (PDT), VK wrote:

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

If my memory serves me well, this is an old hat among several
similar ones. Douglas Crockford, for example, has been preaching
about this. He essentially says that JavaScript is a language
with a number of well-known flaws, and he recommends to work
around them conscientiously by using defensive strategies,
usually a particular coding style and the avoidance of poor
language elements.

In this particular case I believe he recommends always to use
quotes around property names in object literals, right?

If I'm not mistaken, he has also made this a part of the JSON
standard.

Anyway, it may be worth reading his recommendations and perhaps
use JSLint, which would have alerted you to the problem well in
time.

Hans-Georg

VK wrote:

Just nailed down

That is hugely unlikely. You may have just misattributed something but
nailing things down is not in your skill set.

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

The ES 3 rules for object literals requires that the name in any
name/value pair be either an Identifier, a string literal or a numeric
literal. The word "default" is a keyword and Identifiers are not allowed
to be keywords (or reserved words, though some implementations are
tolerant of the latter while not allowing the former).

This restriction on the possibilities for the name in a name/value pair
in an object literal explains why IE produces the syntax error "Expected
Identifier, string or number." when asked to process this code (which is
even unusually explicit for a JScript error message). It is expecting an
Identifier, string or number, but instead encountered a keyword.

}

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

There were plans for ES 5 to remove the restriction as the use of
keywords (and/or reserved words) in that context does not lead to
ambiguities in interpretation. And because of the lack of resulting
ambiguities it is possible for any ECMA 262 implementation to tolerate
keywords in such a context as a syntax extension.

The others (IE, Safari, Chrome, Opera) do consider such code
as a broken switch-case construction

What evidence do you have that any of them are interpreting it as "a
broken switch-case" when any syntax errors they report are much more
likely to be the direct result of its being the broken object literal
that it is?

As I said, it was pretty certain that you had not actually nailed
anything down, and were going to be miss-attributing something. Here it
is; "a broken switch-case construction" when the code in question is
pretty obviously a broken object literal.

so reporting the missing switch clause.

"Expected Identifier, string or number."?

By taking default key into quotes such reading goes away:

because that is a string in place of a keyword.

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,

Well, (and assuming that you are honestly reporting the situation and
did not write this code yourself) if whoever wrote it had given a damn,
or even just tested in a few other environments, they you would never
have been asked to deal with the consequences. The syntax error is
there, and so getting syntax error messages from web browser always was
that likely outcome.

it sucks even carved somewhere on a stone.

The fact that the injunction on keywords in that context can be changed
means that it never was necessary. However, there may have been a time
when the simplicity of distinction between things that were Identifiers
and things that were not made for faster tokenising/parsing/compiling on
hardware that was not nearly as capable as current hardware.

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.

That is you all over; a knee-jerk over-generalised overreaction to being
caught out once again by your not knowing the syntax rules of the
language you are using.

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

The group readers may or may not account this coding advise.

You mean when the advice to write javascript that conforms with ECMA 262
syntax rules will get the job done with less effort?

Richard.

VK wrote:

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,

Thomas 'PointedEars' Lahn wrote:

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

Evertjan wrote:

VK wrote on 24 okt 2009 in comp.lang.javascript:
snip
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.

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

Richard.

Richard Cornford wrote:

(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

VK wrote:

Thomas 'PointedEars' Lahn wrote:
`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
--
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.)

VK wrote:

Thomas 'PointedEars' Lahn wrote:
`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
--
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.)