Implicit object constructor misinterpretation

Hans-Georg Michna wrote:

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?

Is that true? A lot of things get attributed to Douglas Crockford
without there being any evidence of them being attributable to him.

I would expect that if he had made such an injection it would be found
in the text of his "javascript: The Good Parts" (if not in many other
places as well). Looking tat that book, in Appendix A "Awful parts",
under the heading "Reserved Words" (page 103) he writes:-

Most of these words are not used in the language.

They cannot be used in name variables or parameters. When reserved words
are used as the keys in object literals they must be quoted. They cannot
be used with the dot notation, so it is sometimes necessary to use the
bracket notation instead: <RC: followed by a list of examples >

- where the opportunity to propose some SHOULD-style injections is not
taken up. There are also many examples of object literals in the book
where no blanket quoting of keys is evident, for example, on page 25
under the heading "Global Assignment".

Then there is his JSLInt program. There are a number of 'rules' imposed
by JSLint that are the direct result of Douglas Crockford's conclusions
about 'correct' style in javascript authoring. If he believed that it
was a good idea for keys in object literals to always be quoted without
exception then he could easily program such a 'rule' into JSLint. So,
going to:-

<URL: http://www.jslint.com/ >

- and entering VK's original code the error reported is "Problem at line
4 character 3: Expected an identifier and instead saw 'default' (a
reserved word)", as could have been expected.

adding quotes to just the - default - keyword in the code removes that
error message, but does not produce any error messages about the other
keys not being quoted. And looking at the options further down the page
does not even suggest a possible of turning such warnings on (at least
outside of the possibility of explicitly testing JSON text with JSLint,
where you expect JSON rules to be applied).

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

Maybe the "also" does not belong in that sentence.

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

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

Richard.

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.

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

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

<snip>

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
--
John Harris

Richard Cornford wrote:

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.

Evertjan wrote:

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.

Knowable, because ECMA 262 states the list. How logical the list may be
probably depends on perspective. In retrospect words like - let - and -
unit - should have been in the list (as they are things people now want
in the language, and can only be introduced on a context-dependent
basis) and all the class-based stuff need never have been there. In the
past, when the stated intention was to migrate javascript towards being
more Java-like they probably made sense.

Certainly the list is something that is relatively easy to trip over. I
have changed the syntax highlighting rules in my text editors so that
reserved words are displayed in in very obvious 'red on a bright yellow
background' so that I will easily notice my attempts to use them as
variable names. Specifically, if I want a variable to hold a single
character from a string I am always tempted to name it "char", and over
tolerant environments often put up with that, while one or two do not.
No amount of quoting the keys in object literals is going to help there
as variable names cannot ever be quoted, so the syntax highlighting is
probably the best general solution (it is just a pity that text editors
I use have too few categories to make devoting one to keywords a
convenient action).

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],

I am not someone who is going to be found charging a gun emplacement on
horseback armed only with a spear, regardless of any 'authority' telling
me to. ;-)

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.

I really don't know enough about SQL to judge (that is the server-side
programmer's responsibility), though I can't say I have noticed this in
the SQL I have been exposed to.

Richard.

John G Harris wrote:

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.

VK wrote:

John G Harris wrote:
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.

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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

VK wrote:

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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

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


--
http://www.gregorkofler.com

Gregor Kofler wrote:

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