Implicit object constructor misinterpretation

VK <schools_ring (AT) yahoo (DOT) com> writes:

//////////////////////
// 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
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

VK wrote:

Thomas 'PointedEars' Lahn wrote:
`foo' is called an identifier because it must be produced
by the /Identifier/ production.

VK wrote:
Almost perfect, one half in there already!

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

VK wrote:
snip
My question is if it is a Gecko bug, a convenience extension
or the proper implementation by ECMA with others being wrong
on that?

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).
snip
So it is as as earlier explained: property names are
strings, explicitly quoted or implicitly quoted.

No they are not. In ES 5 the syntax for PropertyName in object literals
is:-

PropertyName :
IdentifierName
StringLiteral
NumericLiteral

The difference being that IdentifierName has replaced Identifier in the
list of possibilities. With the consequence that where Identifier is
defined as "IdentifierName but not ReservedWord" and so precludes
ReservedWords, IdentifierName only constrains the possible character
sequences used. That is, - default - satisfies the syntax rules for
IdentifierName but is not an Identifier because it is a keyword, which
in tern is a ReservedWord.

There is still no 'implicit quoting', which, if it did exist is neither
capable of explaining, or necessary to explain, the behaviour that is
observable.

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)

"Non-quoted character sequences in this position", as you put it, are
not "guaranteed to be quoted (treated as a string literal on the
execution stage)". Brendan Eich has never even implied such a thing, let
alone said so. Your asserting your agreement with him in this regard is
seriously disingenuous.

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

Object constructor? You mean object literal. ECMAScript has an "object
constructor" (if not several) and it is something else entirely.

property names are always treated as string
literals,

Sequences of characters in the Property Name context of the source text
for an object literal are absolutely not "always treated as string
literals". If they were the resulting behaviour would be contrary to the
specification(s, ES 3 and ES 5) and so objectively incorrect.

so quotes around them may be omitted in the source code

No. As has been pointed out previously:-

var x = {
####:0
};

- is a syntax error, while:-

var x = {
'####':0
};

- is not. But the handling of numeric literals is also significant as
the string representation of an IEEE double precision number in
ECMAScript does not necessarily correspond with the sequence of
characters in the numeric literal's source text. So:-

var x = {
'1e4': "here"
};

alert('1 ' + x['10000']); //alerts - 1 undefined -
alert('2 ' + x['1e4']); //alerts - 2 here -

var y = {
1e4: "here"
};

alert('3 ' + y['10000']); //alerts - 3 here -
alert('4 ' + y['1e4']); //alerts - 4 undefined -

to
speed up typing and/or for a better code readability.

Justifications for something that does not happen are a little hollow.

The drawback of such syntactical shortcut is that then all
property names have to obey the JavaScript naming rules

The only way to verify that any character sequence does satisfies any
particular set of rules is to first have access to all of that sequence
of characters. Having acquired the character sequence and verified that
it satisfies the rules for either Identifier in ES 3 or IdentifierName
in ES 5, what would be the point of attempting to create a string
literal from it, when it would then be necessary to re-extract that
sequence of characters from the string literal in order to know what
name to give to the created object property? It is much simpler to go
from the Identifier or IdentifierName straight to the name of the new
property.

and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks

That "quirk" being conforming with the language specification?

they may lead to syntax errors. This way it is highly
suggested do not use the above
mentioned syntax shortcut

Your mentioning it does not mean that it exists.

and to use full syntax

What you are calling "the full syntax" is a subset of the syntax.

with quotes around
each property name.

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

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

Programmers or performing seals?

Richard.

Lasse Reichstein Nielsen wrote:

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

Did you hear about
http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#First_incom pleteness_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
//////////////////////

VK wrote:

Lasse Reichstein Nielsen wrote:
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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

VK wrote:

Did you hear about
http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#First_incom pleteness_theorem

Yes. Though you may be unique to date in proposing it as a justification
for not attempting to be consistent in technical explanations.

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

There is nothing wrong with consistent and complete explanations where
they are possible. We are not, after all, in the realm of number theory
here.

But what is your "prove it wrong by ... " about? Generally, a statement
that is contradicted by empirical evidence is wrong. That my not apply
in "VK's universe" but for the rest of that that is something that
nobody bothers arguing about. It is just too difficult to imagine a
rational thought process that would result in you.

I don't -

That has been observed. The only disputable aspect of your behaviour in
this regard is theorising about the explanation.. As you know, I
consider that mental illness on your part is the theory that best fits
the evidence of your actions.

plus I definitely know that there are not any identifiers in
here,

No identifiers?

I like the semantics too much to let them into.

Does that mean something in "VK's universe"?

My explanation remains unchanged.

Evidently, but it also remains needlessly convoluted/complex and
insufficient to explain the reality.

Maybe(?) it is not complete

Maybe?

but it is consistent for any sane practical use.

It is that inability to perceive what a "sane practical use" is that
leaves me leaning towards the mental illness theory. An explanation that
leaves a programmer in a position to accurately predict how the computer
code they write will be interpreted when parsed and behave when executed
has a very obvious use, at least for the rational.

At the beginning I also though to add "to syntax errors or to
unforeseen results" with
var obj = {
300000000000000000003 : 0,
3000000000000000000003 : 0
};

Bullshit.It the incompleteness of your understanding of the subject that
leads you to miss this short of thing out.

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.

An unrealistic task. People explore, and then they come here looking for
explanation of what they find, at least if they cannot find an
explanation for it on their own. That is entirely understandable and
expected, but it is best if when they receive the explanation they do
not have to tare down some previous fantasy explanation into which their
new discoveries cannot fit.

Of course, if you don't require consistency in your understanding of a
subject there is no need to modify pre-existing fantasies when
contradictory evidence is encountered. No, in "VK's universe" you put
your fingers in your ears and sing "La la la" until you can "lock such
path for thinking completely".

"syntax error" sounds short and serious,
verbosed explanations of possible problems spoil the effect.

That effect would FUD?

(Fear, Uncertainty and Doubt:-
<URL: http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt >
)

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.

What has that got to do with anything?

//////////////////////
// explanation starts
snip: Nothign worth seeing here.
// explanation ends
//////////////////////

Richard.

On Oct 25, 5:26*am, "Richard Cornford" <Rich... (AT) litotes (DOT) demon.co.uk>
wrote:

Thomas 'PointedEars' Lahn" wrote:
Richard Cornford wrote:

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"?

Yes I did.

As for the rest, thank you for your patient explanations. *One can
only hope something of it gets through to him.

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.


--
Rob

Richard Cornford wrote:

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.

RobG wrote:

"Richard Cornford" wrote:
Thomas 'PointedEars' Lahn" wrote:
As for the rest, thank you for your patient explanations. One can
only hope something of it gets through to him.

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.

Full ACK. I would like to volunteer for the prufreading the speling ;-)


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

Thomas 'PointedEars' Lahn wrote:

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.