Implicit object constructor misinterpretation
VK
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
--
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.)
Evertjan.
"> 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)
Hans-Georg Michna
>... 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
Richard Cornford
> 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
> > 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.
Richard Cornford
> VK wrote on 24 okt 2009 in comp.lang.javascript:
>> 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.
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
> 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.
Richard Cornford
> 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.
Evertjan.
>> 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
<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
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.
Richard Cornford
> 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.
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
> 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
Gregor Kofler
[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
> 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
Richard Cornford
> 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.
Why not? Brendan Eich invented that language and Brendan Eich sat on the
committee(s) that wrote the spec(s). If the committee members had any
questions bout intentions they also had direct access to the answers to
those questions.
> 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,
Netscape 4 was an ECMA 262 2nd Ed. implementation, that version of
ECMAScript does not include function expressions at all. So in that
environment they were a syntax extension, and probably an experimental
one at that.
> for Eric Lipper porting it to IE.
No he didn't. at least that is not what JScript does, or ever has done.
In JScript the construct:-
(function f() {
})();
- results in the creation of two function objects. The first during
variable insanitation as the execution context is entered, which is then
assigned as a property named 'f' on the applicable Variable object. The
second during the evaluation of the expression, where that second
function object gets called. If code in either of the two functions
attempted to use the Identifier - f - to call a function then it would
be he first of these two function that would be the one called.
This behaviour in JScript is sufficiently irrational that there is
virtually zero chance that it exists by design (i.e. it is a bug, even
without considering what any ECMA standard may say on the subject), and
it certainly will not represent a (sucessful) porting of anything that
was done in pre-existing Netscape browsers.
> 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.
JScript did not claim to be a ECAM 262 3rd Ed implementation (the first
version of the standard to include function expressions) before version
5.5, so while it did not make the claim it could not be faulted for not
satisfying the claim. As soon as the claim to be a conforming
implementation is made any failure to conform is a bug by language
specification.
> 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.
No, that is interpreted as a syntax error. Labelled statements, being
statements, cannot appear on the right hand side of a comma operator
(only an Expression may appear in that context). Changing the comma to a
semi-colon, or just removing the comma while retaining the line
terminator, removes the syntax error, but both actions preclude even the
possibility that the construct be used in an object literal context a
then it becomes a different syntax error.
> {
> 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.
Which might be more meaningful if you first example had not also been a
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.
Haven't I already pointed out what a nonsense this proposal that some
sort of 'automatic quote insertion' happens during tokenising/parsing
is? I suppose that just went straight over your head again. If that
could happen then all sorts of possibilities would come into play.
Rather the situation is relatively simple. The evaluation of an object
literal results in the creation of a new object and for each name/value
pair in the literal a new named property is added to that object where
the rules for determining the character sequence in that name are:- if
the name part is an Identifier then the character sequence from the
Identifier is used as the new property's name, if the name part is a
string literal then the character sequined from the string literal is
used as new property's name, and if the name part is a numeric literal
that is evaluated to produce the number value and that numeric value is
type-converted into a string, and then that character sequence form that
string is used as the new property's name.
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. There is no reason for any 'automatic
quote insertion' not to accommodate the former.
var x = {
x:1,y:2
};
- is a valid object literal, and so is:-
var x = {
'x:1,y':2
};
Similarly:-
var x = {
':::::':0
};
- is a valid object literal, but:-
var x = {
::::::0
};
- never could be, except that, if they existed, it could be rendered
valid by some sort of 'automatic quote insertion' rules.
var x = {
'@@@@@':0
};
- is fine, but you won't get awya with:-
var x = {
@@@@@:0
};
> 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.
Only in the sense that the behaviour resulting form the use of an
identifier in the name part of an object literal is already well
defined.
> 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:
You see, your over-elaborate fantasy of 'automatic quote insertion'
needs a whole list of special cases to account for what javascript
actually does. You have problems accounting for any used of key/reserved
words, for expressions, for unexpected character sequences. So on top of
what you have you also need a massive array of additional rules.
The alternative of, if it is an Identifier, a string literal or a
numeric literal it will be predictably handled, and if it is not then a
syntax error should be expected, covers the situation nicely. And if
some implantations want to extend either the definition of Identity, or
the named part of an object literal, to include reserved words then that
does not introduce much additional complexity.
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.
> now no, it is not a constructor but a block of
> statements with the second one preceded by an illegal
> label literal.
No it isn't. It is just an object literal that contains a syntax error.
Earlier today you were asserting that including the 'default' in an
object literal was resulting in its interpretation as a "a broken
switch-case construction", and I asked you what evidence you had for
that assertion. You never were going to provide any such evidence as you
never had any. Instead you had just made that assertion up off the top
of your head. Here again you are making this up off the top of your
head. For a start, the interpreter is very unlikely to ever switch to
attempting to interpret this as a Block statement for the simple reason
that no Statement is allowed to be the right hand side of an assignment
operation. By the time the parser has seen the assignment operator (the
single = sign) we are in an Expression context, and the only question is
whether what follows is a syntactically correct Expression or not.
> Some might find it very logical. I am definitely not in
> that club.
If even you do not find your own fantasies logical why do you bother
anyone else with them?
Richard.
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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
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
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> 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
--
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$8300...@news.demon.co.uk>
Richard Cornford
> Richard Cornford wrote:
>> 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 ...
November the 26th is not a Monday.
> 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 ;)
No, that is arbitrary rules on top of syntax rules. The key/reserved
word rule issue applies to all instances of Identifier use; function,
variable and parameter names, dot notation property accessors, object
literal names, etc. If the person doing the programming understands the
syntax rules then they don't need the addition rules, and if they don't
understand the syntax rules then the additional rules will not render
their output error-free (even with regard to Identifier/reserved word
issues). You are, as usual, attempting to solve the wrong problem.
> For the Fx (ab)normality I am going to ask out of curiosity at
> mozilla.dev.tech.js-engine
On your record of such promises, I will not be holding my breath.
Richard.
Richard Cornford
> 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. ;-)
Richard.
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
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
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
> Lasse Reichstein Nielsen wrote:
>> 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'
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".
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
> 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'
Richard Cornford
I notice that you didn't ask about your fantasy 'automatic quote
insertion', if the interpreter "changes its own previous decision" or
any of that noise you made about the syntax error resulting in the code
being interpreted as "a broken switch-case construction", and/or "a
block of statements with the second one preceded by an illegal label
literal". Probably a good thing as that avoids anyone who actually codes
ECMAScript implementations and reads the propositions suffering fatal
seizures while laughing at you nonsense.
And the (second) answer you got (assuming you are willing to take
Brendan Eich's word as final) is precisely the same as the first one you
got here: ES 3 does not allow keywords as the names in object literals,
but does allow for their acceptance as a syntax extension, and ES 5 will
explicitly allows them. Thus none of the browsers observed are behaving
incorrectly with the example code, and the 'problem' is with the
understanding of the language's syntax possessed by its author.
Richard.
VK
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
<snip>
>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.
--
John Harris
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!
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 = {
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> here! `foo' is called an identifier because it must be produced by the
>> /Identifier/ production.
>
> 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
--
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
> >> `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:
>
> > > Having a statement such as:
>
> > > var obj = {
> > > foo: 'bar',
> > > default: 'default_value'
> > > }
>
> > > Firefox 3.5.3 creates obj with properties foo and default.
>
> > > IE reports syntax error "Expected identifier, string or number", same
> > > or similar syntax error occurs on Safari, Chrome and Opera. By placing
> > > default into quotes we are making the code valid for all browsers in
> > > question:
>
> > > var obj = {
> > > foo: 'bar',
> > > 'default': 'default_value'
> > > }
>
> > > 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).
>
> 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:
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> >> `foo' is called an identifier because it must be produced by the
>> >> /Identifier/ production.
>
> VK wrote:
When will you ever learn?
>> > 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. [...]
Idiot.
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)
Richard Cornford
> 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:
>>>> 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).
> 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.
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
VK
http://en.wikipedia.org/wiki/G%C3%B6del%27s_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
> 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 ...
Richard Cornford
> Did you hear about
> http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#First_incompleteness_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.
RobG
wrote:
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
optimistx
> As you know, I
> consider that mental illness on your part is the theory that best fits
> the evidence of your actions.
Thomas 'PointedEars' Lahn
Full ACK. I would like to volunteer for the prufreading the speling ;-)
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.
Richard Cornford
>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
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."
"due to some parser quirks they may lead to syntax errors"
"do not use the above mentioned syntax shortcut and to use full syntax
with quotes around each property name"
> in object constructors
They are still object literals not object constructors.
> property names are not evaluated and treated as strings even
> if quotes are omitted
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.
> which is allowed for simplicity;
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.
> but if quotes are omitted, some troubles are possible on
> the parsing stage so better to use them.
The only possible trouble is that if the construct created does not
conform with the syntax rules it will result in a syntax error.
> Simple and clear.
As with much you write, it gets clearer as you edit more out. There is
no more talk of "syntax shortcut", "full syntax with quotes around each
property name" the quotes will be added automatically", "one of reserved
words in the parser list AND it changes its own previous decision", "it
is not a constructor but a block of statements", "consider such code as
a broken switch-case construction", etc. But pretending that you have
been right all along because you are no longer repeating some of the
more obvious nonsense is unlikely to fool anyone.
> Now look at all this squealing and whining produced just because
> VK said it, not some of His Majesties.
It was what you said that has been criticised here.
> 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).
You mean they are processed as Identifiers if they are Identifiers?
> They are not identifiers
Yes they are.
> and they are not becoming identifiers out of being processed
> by this rules.
If they were not Identifiers they would not be processed as Identifiers.
Of course this nonsense has something to do with your odd beliefs about
Identifiers. We don't have to worry about those as the spec clearly
states what an Identifier is, and that is the only definition relevant
to the parsing of javascript source code.
>2) At run-time unquoted keys are acting as string literals,
> even if not quoted -
Runtime behaviour is irrelevant to questions of tokenising/parsing. A
syntax error guarantees that no code will be executed, and so no runtime
behaviour will happen.
> so "auto-quoted" as I said but you don't need to use this
> term if it is such an irritation to you
If the runtime process of object construction uses the character
sequence in an Identifier to create a string value that will become a
property name of the created object that still does not justify any
notion of 'adding quotes'. For one thing, the significance of quotes is
completely gone by runtime as string literals in the source code (where
quotes do have significance) have already taken on their complied form.
At this point we are beyond questions of syntax, "shortcut syntax",
"full syntax" or otherwise.
> Other words you just spent 10 times more words to say what
> I said.
Telling a lie is easy, it tends to take more effort to show that it is a
lie.
> 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.
To show that any notion of 'automatic quote insertion' contradicted
the observe behaviour, and so that there is no "full syntax with quotes
around each property name".
> That the advise to always use quotes is wrong?
That is a different issue. That advice is patronising, needlessly
inconvenient, unnecessary for anyone who knows the syntax rules for the
language and insufficient to address the full issue when taken by those
not familiar with the language's syntax rules. It is a knee-jerk
overreaction from someone who had no business not knowing enough to
recognise the issue when encountered.
> It failed then.
Yes it probably did.
> That keys do not act at runtime as implicitly or
> explicitly quoted string literals?
The issue that quoting all property names in object literals is aimed at
addressing is a syntax/parsing issue, so runtime behaviour is an
irrelevance. You cannot talk of "full syntax with quotes around each
property name" and then attempt to justify that with runtime behaviour.
> It failed than. I really didn't get what that verbal diarrhea was
> about,
It was about an extended fantasy nonsense being posted as a needlessly
complex alternative to a technical explanation.
> except maybe to make everyone to
> believe that JavaScript is a hugely enormously complicated
> language which it is not at all.
You were the one insisting on adding your fantasy notions on top of what
really happens.
> It just like with the prototype inheritance
> which is simple as a moo cow yet never was normally
> explained here over all these years:
Or at lest you have never understood any explanation given, and have
talked a lot of nonsense on that subject as well.
> 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.
"You guys are such boring dicks"?
Richard.
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.
> > but if quotes are omitted, some troubles are possible on
> > the parsing stage so better to use them.
>
> 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" :)
> > Simple and clear.
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?
>
> > They are not 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.
> > and they are not becoming identifiers out of being processed
> > by this rules.
>
> 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.
Lasse Reichstein Nielsen
> 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
Agree.
> 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.
No, it's purpose is to *define* the language. Not the internal
algorithms, but the syntax and semantics of it.
The algorithms given in the specification is not something you must
follow, as long as what you do gives the same result.
I must admit that there are places where the format has affected
the specification more than I think is necessary.
In this case, that's not relevant, though, because we are talking
about syntax.
> 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.
I do think you have a point, but your presentation of the point
is marred by you making the same mistake of mixing terminology from
different phases.
> One more time, very slow: parsed by the rule of an identifier !== to
> be an identifier.
Here you seem to have an idea what it means to be an "identifier".
In Javascript, being an identifier is a tokenization concept. The
thing you seem to think about is called "variable".
> In object constructor all key values are string
> literals, explicitly or implicitly quoted.
The concept of "string literal" is again a tokenization/parsing
concept. String literals are sequences of characters flanked by either
single or double quotes. They are parsed, and evaluated into string
values.
You cannot quote a string value. Being quoted is a syntactic concept,
which happens even before tokenization.
> 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.
Which is, perhaps, why your explanation isn't being accepted - you uses
parsing/tokenization concepts it.
...
>> "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.
You can't add quotes after tokenization, so if you say that quotes
are added, it must be at the level of tokenization, at the latest.
My guess is that this better matches what you mean:
In object literals, all keys are string values. They can be written
as string literals, or as identifiers or number literals, which is
then converted to string values. Identifiers may not include language
keywords, and numbers are always converted to their canonical string
form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted.
Thomas 'PointedEars' Lahn
> VK <school...@yahoo.com> writes:
>> 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
>
> Agree.
IBTD!
VK
> > parsed by the rule of an identifier !== to
> > be an identifier.
Lasse Reichstein Nielsen wrote:
> Here you seem to have an idea what it means to be an "identifier".
> In Javascript, being an identifier is a tokenization concept. The
> thing you seem to think about is called "variable".
No, I think exactly about *identifiers*. Identifiers and variables are
circa in the same relations as human names and human beings
themselves. One person can have several names (Edgar Allan Poe) and
several people can have the same names being distinguished by other
criteria (addresses etc.)
Again:
http://en.wikipedia.org/wiki/Identifier#Identifiers_in_computer_languages
"In computer languages, identifiers are tokens (also called symbols)
which name language entities. Some of the kinds of entities an
identifier might denote include variables, types, labels, subroutines,
and packages."
http://en.wikibooks.org/wiki/C++_Programming/Code/Style_Conventions/Naming_identifiers
"Identifiers are names given to variables, functions, objects, etc. to
refer to them in the program."
The purpose of an identifier is to name something, it is its core
feature and it implies its univalence within the given scope. Other
words identifier foo may identify the most different variables on each
program step (foo=true; foo=bar; foo=null) but it must not identify
two or more different variables at the same time as it ends the
program integrity.
And no, identifiers in JavaScript do not have some special naming-
unrelated function, let's not pretend that JavaScript is from Mars
while all other programming languages are from Jupiter. Higher level
entities may bear different meaning by languages, say "static" method
in C, Java and Visual Basic/VBA mean such different things that they
have nothing in common at all, except the same six letters used to
denote them. But the core entities (algorithm, program, condition,
identifier, subroutine etc.) are the same irrelevant to possible
verbal oopses in this or that document.
VK writes:
> > In object constructor all key values are string
> > literals, explicitly or implicitly quoted.
Lasse Reichstein Nielsen wrote:
> The concept of "string literal" is again a tokenization/parsing
> concept. String literals are sequences of characters flanked by either
> single or double quotes. They are parsed, and evaluated into string
> values.
> You cannot quote a string value. Being quoted is a syntactic concept,
> which happens even before tokenization.
var foo = 'bar';
var obj = {foo : true};
Will it produce obj with property name 'foo' or with property name
'bar'? Is the result caused by parser rules or by language rules
stating that in this particular position it must be a string literal,
either programmer surrounds it by quotes or not?
...
> You can't add quotes after tokenization, so if you say that quotes
> are added, it must be at the level of tokenization, at the latest.
Disagree with you on that as it implies some mechanicism of the worst
kind in the whole programming (not JavaScript only) with the
programmer being some toy in hands of "pre-programmed elements". If a
programmer types:
var foo = 'bar';
var obj = {foo : true};
he means something at the moment of typing, same way as with the
casual writing. If he means "use the string value 'bar' identified by
foo as the property name in obj" then he simply makes a program
mistake. If he properly means "use string literal 'foo' as property
name in obj" then it is the implicit quoting provided by the language
and used by the programmer: and the implicit quoting happens right
here and then, on typing, not some later out of "good heartiness" of
some C subroutine.
To make it even more clearer let's take Perl where this convenience
typing shortcut was taken from into JavaScript back in 1995:
%obj = (
foo => 'bar',
bar => 'foo'
);
Are we having here foo and bar "identifiers" that become string
literals on the parsing stage? Of course not, these are string
literals written by the programmer using documented shortcuts.
> My guess is that this better matches what you mean:
>
> In object literals, all keys are string values. They can be written
> as string literals, or as identifiers or number literals, which is
> then converted to string values. Identifiers may not include language
> keywords, and numbers are always converted to their canonical string
> form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted.
Something that cannot be an identifier or number in a given position
cannot be written "as identifiers or number literals". Yes, a
convenience shortcur was taken but the necessary parser logic was not
added to save on parsing time and now it is necessary to deal with it:
but without introducing "non-identifier identifiers", deferred to the
parsing stage programming logic and similar bizzarities.
IM_strong_yet_HO
VK
> >> 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
Lasse Reichstein Nielsen wrote:
> > Agree.
Thomas 'PointedEars' Lahn wrote:
> IBTD!
It is a unmoderated newsgroup, so don't worry
http://www.urbandictionary.com/define.php?term=ibtd
John G Harris
<snip>
>The purpose of an identifier is to name something,
<snip>
Very true, and in this case it names a property.
However, the language's syntax rules give you three ways to name a
property in an object literal, viz :
as an Identifier
as a StringLiteral
as a NumericLiteral
and it's the job of the parser to cope with all three possibilities and
extract the appropriate property name and deliver it to the next stage
of compilation.
In that next stage you might want to call it an "identifier", but try
not to get confused between the syntax rules that programmers have to
know about and the internal workings of the compiler, which they don't.
John
--
John Harris
VK
>
> <snip>
>
> Very true, and in this case it names a property.
Well, it was already suggested as a joke in my post at
http://groups.google.com/group/comp.lang.javascript/msg/add1efacca25c5b2
"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".
If you - or anyone else - liked the joke so much that decided to use
it seriously then of course it's your decision: just don't get upset
if others will keep considering it as a joke. Also for the appropriate
transformation of a joke into a serious theory some extra job should
be suggested. In the particular IMHO it is necessary to introduce a
class of "bivalent number literal identifiers" (BiNuLid) that either
used to express numbers or used to identify object property names. In
the last case the identified property name is not directly connected
with the BiNulid's literal form. A few examples of BiNuLids:
300000000000000000003 identifies property name "30000000000000000000"
3000000000000000000003 identifies property name "3e+21"
Overall as I said in the linked post, having enough of beer, spare
time and absolutely nothing better to do, the theory can be brought to
a profoundly perfect dogmatic form (yet remain utterly useless as
such).
> However, the language's syntax rules give you three ways to name a
> property in an object literal, viz :
>
> as an Identifier
> as a StringLiteral
> as a NumericLiteral
No, the language gives you only one option to name a property in an
object literal, this is a string literal. The language allows you to
be lazy and skip on quotes, but you should be very careful with it
because unlike in other languages with such convenience shortcut,
JavaScript parser doesn't have extra logic added to handle it
properly.
...
John G Harris
<snip nonsense>
>> However, the language's syntax rules give you three ways to name a
>> property in an object literal, viz :
>>
>> �as an Identifier
>> �as a �StringLiteral
>> �as a �NumericLiteral
>
>No, the language gives you only one option to name a property in an
>object literal, this is a string literal. The language allows you to
>be lazy and skip on quotes, but you should be very careful with it
>because unlike in other languages with such convenience shortcut,
>JavaScript parser doesn't have extra logic added to handle it
>properly.
The programmer who codes the parser has a function to handle an
Identifier, a function to handle a StringLiteral, and a function to
handle a NumericLiteral all to hand and tested in many releases. But,
you say, he doesn't use them for object literals because he wants to
write the code all over again to do the same job. He ought to be sacked
for doing that.
KEEP IT SIMPLE!
John
--
John Harris
Lasse Reichstein Nielsen
>> However, the language's syntax rules give you three ways to name a
>> property in an object literal, viz :
>>
>> �as an Identifier
>> �as a �StringLiteral
>> �as a �NumericLiteral
>
> No, the language gives you only one option to name a property in an
> object literal, this is a string literal.
No! It is a string *value*!
There are three ways to specify that string value:
Identifier, string literal and number literal.
Please distinguish literals (syntax) from values (semantics)!
VK
wrote:
> VK <schools_r...@yahoo.com> writes:
> >> However, the language's syntax rules give you three ways to name a
> >> property in an object literal, viz :
>
> >> as an Identifier
> >> as a StringLiteral
> >> as a NumericLiteral
>
> > No, the language gives you only one option to name a property in an
> > object literal, this is a string literal.
>
> No! It is a string *value*!
http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters
Why is it important to say "string literal" and not "string value"?
Because this is the point that distinguishes strings here:
var s = 'foobar';
and say here:
var s = 'foo'+'bar';
other words literal and expressions / return values / whatever which
may well be string values.
> There are three ways to specify that string value:
> Identifier, string literal and number literal.
>
> Please distinguish literals (syntax) from values (semantics)!
I pretty much understood the point expressed by you and by other
participants. In JavaScript an identifier is whatever is treated on
the parsing stage by identifier parsing rules. Harris' variation:
identifiers that identify string literals resulting from the parsing.
foo identifies property name "foo"
0144 or 0x64 or 100.0 or 100 identify property name "100"
etc.
As I said such "philosophic mechanicism" may be understood after some
efforts, but I am strongly opposing to any attempt to say that this
has anything to do with any common programming terminology or
thinking.
P.S.
var obj = new Object;
obj[0144] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);}
Rather than create some really special programming terms and almost
programming schools just take that the guys were too busy with other
stuff when making JavaScript1.2 so just added implicit constructors
with syntax shortcut atop already rather weird per-property
constructor so the system is as it is but of course without any "non-
identifying identifiers" and stuff.
P.S.S. Yet of course some regulars already might have a set of
definitions for say
obj[-100] = true;
without any "implicit quoting"
But why not just KISS ? Only to be not like everyone?
Lasse Reichstein Nielsen
> On Nov 1, 1:15�am, Lasse Reichstein Nielsen <lrn.unr...@gmail.com>
> wrote:
>> VK <schools_r...@yahoo.com> writes:
>> > No, the language gives you only one option to name a property in an
>> > object literal, this is a string literal.
>>
>> No! It is a string *value*!
>
> http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters
>
> Why is it important to say "string literal" and not "string value"?
Because they are different and live in different domains. Evaluating
expression syntax creates values. A string literal syntax evaluates
to a string value.
> Because this is the point that distinguishes strings here:
> var s = 'foobar';
> and say here:
> var s = 'foo'+'bar';
> other words literal and expressions / return values / whatever which
> may well be string values.
Indeed. A string literal is a piece of syntax.
In the above 'foobar' is a string literal (eight characters, including
the single quotes), which is also an expression. It evaluates to the
six-character string consisting of the letters f, o, o, b, a and r.
And 'foo' + 'bar' is an expression using the '+' operator on two
sub-expressions that are each string literals. It evaluates, in a
number of steps, to a string value indistinguishable from that of
'foobar'.
The representation of a string value is unknown to the user,
it merely acts as a member of the String type when accessed by the
program.
The representation of a string literal is a sequence of characters
in the program source.
Keys in objects are string values.
In object literals, these string values can be represented by either
string literals, identifiers or number literals.
You keep comming back to unquoted literals and numbers as being merely
shorthands for writing string literals without the quotes.
Thinking of how the language was developed, I don't think that was the
reasoning (without actually knowing it, not being B.Eich).
In JavaScript, objects fills several roles:
- They are object oriented objects, with fields and methods known
to the programmer. These are typically accessed using
identifiers, e.g.:
o.method(o.property), array.substring(array.length - 2)
- They are arrays, indexed by integers, including number literals:
a[42] or a[numbervar]
- They are generic maps from strings to values, indexed using
strings, including string literals:
m["foo"] or m[stringvar]
It makes sense that object literals can be specified in all of these
ways too, even though the underlying object implementation uses
strings for all properties.
var o = { get : function() { return this.x; },
set : function(x) { this.x = x; },
x : undefined };
var a = { 0 : 42, 1 : 13, length: 2 };
var m = {"foo" : o,
"bar" : a };
From the language point of view, they all make their own sense for
differt types of objects, not just as shorthands for map entries.
Sherm Pendley
> Why is it important to say "string literal" and not "string value"?
For the same reason it's important to say "orange" and not "apple"
when you are in fact talking about oranges.
> But why not just KISS?
Simple is good. Over-simplifying to the point of being incorrect is not.
sherm--
John G Harris
<snip>
>Harris' variation:
>identifiers that identify string literals resulting from the parsing.
<snip>
Not my variation; it's your variation. I suggested you were using
'identifier' as an alias for 'property name', the thing that identifies
a property when the program runs.
Inside the compiler the property name won't be held as a string literal.
If the program is written in C++ then it will most likely be held as a
member of the wstring class; if in C then it will most likely be held in
an array of wchar, ending with a 0x0000 character.
John
--
John Harris
VK
> I suggested you were using
> 'identifier' as an alias for 'property name',
> the thing that identifies
> a property when the program runs.
Well, this doesn't work because it doesn't have sense in the
programming. I altered it a bit to be if not too useful then at least
sensual:
The identifier foo identifies a variable foo in the context of Global
or function scope. In an implicit object constructor if used in the
position of the property name it identifies string literal "foo" - or
globally: any valid identifier in the position of the property name in
an implicit object constructor identifies string literal consisting of
the character sequence forming the said identifier.
This is an extremely weird approach of course but at least it has some
sense within the human programming science.
Another option - other than claiming your quoted statement be a lore
from the Alpha Centauri programming school :) - is to stop writing
"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
capitalization and proper reference so then make it clear that you are
not talking about a programming entity but about a charcode sequence
defined by such and such formal criteria. Then:
Any valid ECMA 262 3rd.ed. Identifier in the source code in the
position of the property name in an implicit object constructor is
used as string literal consisting of the character sequence forming
the said Identifier.
This is an extremely weird approach as well but OK, everyone goes to
the hell by his own road :)
P.S. I see that everyone tried to ignore my little homework so humbly
repeating it :)
var foo = 'bar';
var obj = new Object;
obj[foo] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);} // "bar", "-100"
1) What is the difference between a Harris' "parsing stage ECMA 262
3rd.ed. Identifier" on and an "identifier" in the casual programming
sense in the program itself.
2) Comment on the second result without using words "to quote" and
"quotes"
Richard Cornford
<snip>
> P.S.
> var obj = new Object;
> obj[0144] = true;
> obj[-100] = true;
> for (p in obj) {window.alert(p);}
> Rather than create some really special programming terms and
> almost programming schools just take that the guys were too
> busy with other stuff when making JavaScript1.2 so just added
> implicit constructors with syntax shortcut atop already rather
> weird per-property constructor so the system is as it is but
> of course without any "non- identifying identifiers" and stuff.
You are gibbering incoherently again.
> P.S.S. Yet of course some regulars already might have a set of
> definitions for say
> obj[-100] = true;
> without any "implicit quoting"
Yes, and given that example (though what you imagine it to be an example
of is as unclear is you usually leave it) it is extremely unlikely that
you understand that code to start with.
Bracket notation property accessors contain an Expression between their
brackets. That expression is evaluated and the results of evaluating
that expression is type-converted into a string value. Upon assignment
that string value is used as an argument to an object's internal [[Put]]
method, which in the case of an object hat does not already have a
property with the a name that corresponds with the string value, results
in the creation of a property of that object which does.
Now, your Expression is -100 which is not as simple an Expression as
it appears. It is an underrepresented fact that javascript numeric
literals cannot define negative numbers. Which brings us to another
example of something that is a syntax error by specifications but could
easily be accommodated if there was 'implicit quoting' or some form of
'automatic quote insertion' going on. That is:-
var x = {
-1:'somethong'
};
- is a syntax error because the item in the property name context is
none of an Identifier, a string literal or a number literal. It is an
expression. However:-
var x = {
"-1":'somethong'
};
- is fine. yet another example of a truth that is not necessarily
consistent with any notion of 'implicit quoting'.
So the Expression -100 is not a number literal, it is an expression
consisting of the unary minus operator with a numeric literal as its
operand. Thus the evaluation of the expression involves evaluating the
numeric literal to a numeric value, and then applying the unary minus
operator to the result, which is then a negative numeric value.
> But why not just KISS ? Only to be not like everyone?
Simplify that is the result of ignoring various aspects of the reality
is only the illusion of simplicity.
Richard.
Richard Cornford
>> 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.
Agreeing with yourself is a little redundant. I quoted those as examples
of what you actually had stated, where you were trying to make out that
you had actually stated something else entirely. I assume that your
agreement with yourself above represents a re-iteration of your original
statements.
The above is, at best, a speculation about the motivation of the
original creators of object literals, and a speculation about motivation
with regard to something that does not apply to its subject. There is no
sense in "omitted" as not having quotes around the property name part of
an object literal changes the nature of the token.
>> "due to some parser quirks they may lead to syntax errors"
>
> Right.
Where those "quirks" represent conforming with the syntax rules as
specified for the language that is being parsed.
>> "do not use the above mentioned syntax shortcut and to use full
>> syntax with quotes around each property name"
>
> Right.
Where what you are describing as "the full syntax" is nothing but a
sub-set of the syntax for object literals.
>> 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
That would depend on what you mean by "learn the language". It is not a
document that will teach anyone how to program with javascript. It is,
however, the optimum document for understanding precisely how the
various constructs used in javascript behave, being the specification
for that behaviour.
Consider the issue in your OP; you can (and you did) speculate about
"broken switch-case" or "not a constructor but a block of statements",
but an examination of the spec shows that the observed behaviour
corresponds with the specified behaviour, and explains the specified
behaviour. Thus avoiding much time wasted in considering irrelevant
alternatives.
> because its main purpose is not to explain the language, but
> to describe the internal algorithms
ECMA 262 is very explicit about stating that implementations are not
required to implement any of its algorithms, rather they are required to
behave precisely as if they did implement those algorithms. That is, it
is a specification of required behaviour, not a source of instructions
on how that behaviour must be achieved.
> so make it possible to
> write compliant engines for other than Netscape browsers.
The method the specification adopts in order to facilitate the writing
of compliant engines is to fully define the behaviour expected of such
an engine. The effect of that is to make the document _the_ source for a
full definition of the behaviour expected of an ECMAScript
implementation.
Another obvious function for the specification is to provide a
vocabulary of technical terms for use when talking about javascript that
have the advantage of being objectively defined. Thus, people can talk
about Activation objects, execution contexts, etc, and everyone else can
know what they are talking about with sufficient precision to allow the
truth of such statements to be objectively examined.
Of course, you do not like that latter consideration at all because
little exposes inconsistent/incomplete explanations faster than the use
of precise and objectively defined terminology. You would prefer
everything to be expressed in a form that represents nothing more
certain than the sort of vague mush that is the usual product of your
thought process.
> The difference is as between say a Perl user reference and
> comments for C libraries used for Perl processor.
Does Perl not have a specification, or do you believe that the people
who really know Perl well do not know/understand that specification?
> As the result some regulars know some really refined
> internal mechanics, some of which even never did into
> any actual implementation,
The question is not whether an implementation implements any particular
algorithm or not, but rather whether it behaves as if it implemented
those algorithms. Failing to behave as if it implements all the
algorithms while claiming to be an ECMA 262 conforming implementation
constitutes a language bug. Unsurprisingly, it is necessary to know (or,
at minimum, refer to) those algorithms in order to be in a position to
declare any particular observed behaviour correct or incorrect.
> yet having troubles to get some obviousnesses.
Obviousness is, pretty much by definition, a subjective judgment. You
always have tended to see certain things as obvious where others
perceive then as anything but, and not to see at all some things that
others perceive as obvious.
> In the particular and most importantly they are normally having
> big time troubles to distinguish *language* features and
> *underlaying C-based engine* features
Underlying implementation details are almost completely irrelevant to
any discussion of javascript. We have a language that is designed to be
independent of everything but its host API/Object Model, and a language
that can be implemented in pretty much any other language. There is
certainly little point in considering some "C-based engine" when there
are so many implementations that are not "C-based" such as Rhino being
an implementation in Java, reference implantations being created in ML
and even javascript based implementations such as Narcissus. It is
actually very unlikely that the approaches taken towards an
implementation in C (or C++) is even applicable in any alternative
implementation language.
If anything, it strikes me that it is you who tends to fixate on
irrelevant details of particular implementations.
> and consequently having troubles to separate properly
> tokenizing, parsing and execution stages,
What evidence do you base that assertion on?
> 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:
Because it proved so convincing the last half dozen times?
> parsed by the rule of an identifier !== to
> be an identifier.
For someone who comments of other's failure to "separate properly
tokenizing, parsing and execution stages" it is ironic that you talk of
"parsed by the rule of an identifier" when Identifiers are tokens (see
section 7.5 "Tokens"), and so the product of tokenising not parsing.
> In object constructor
You mean object literal?
> all key values are string literals,
No they are not. They are Identifiers, string literal or numeric
literals.
> explicitly or implicitly quoted.
There is no need for 'implicit quoting', and if it did exist there would
be may constructs that could be allowed in the context of the property
name part of an object literal (because they would not be ambiguous) but
are not allowed in that context.
> Again, we are taking about
> JavaScript, so about the execution stage.
No, we are talking about the difference between constructs that result
in syntax errors and constructs that do not, so the pertinent stage is
the parsing stage.
Observe, for example, that:-
var x;
if(false){
x = {
#:1
};
}
- is still a syntax error even though the code for the object literal
cannot ever be executed.
> What and how exactly C program treats the source code stream is
> irrelevant here
Any C program is irrelevant (especially given that there is no need for
the parser to be a C program, and plenty of examples that are not). On
the other hand, the specification makes statements about how any
javascript implementation is supposed to behave in tokenising and
parsing in addition to execution.
> yet might be interesting in other circumstances.
>
>>> but if quotes are omitted, some troubles are possible on
>>> the parsing stage so better to use them.
>>
>> 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" :)
The "trouble" here is a consequence of not knowing the syntax for the
language, and nothing else. Syntax errors are a likely consequence of
not knowing the syntax of the language you are using, and such errors
can occur in any context. Attempting to address that situation by
requiring that the property name parts of object literal always take the
form of string literals will not address the syntax errors the ignorant
author will inevitably create elsewhere.
>> > Simple and clear.
>
> Indeed
You are agreeing with yourself again.
>> 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,
No they are not.
> explicitly or implicitly quoted. Again, we are taking
> about JavaScript, so about the execution stage.
Despite the fact that the code for an object literal does not
necessarily ever get executed and that syntax errors happen to the
exclusion of execution?
> What and how exactly C
> program treats the source code stream is irrelevant here
And doubly so for implementations in Java, ML or javascript.
> yet might be
> interesting in other circumstances.
>
>> "the quotes will be added automatically"
>
> See right above.
See what "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.
When you make up your own "parser rules" they do not then constitute a
weakness in �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.
You don't say.
> "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.
What you are saying is that not knowing the syntax rules leaves you not
knowing the syntax rules, and so wasting your time as a consequence. You
may notice how quickly it is for someone who does know the syntax rules
to spot the issue and correctly attribute it, despite their possibly
being familiar with the specification.
> Yet you may order some champagne to celebrate if you wich :)
>
>> You mean they are processed as Identifiers if they are Identifiers?
>>
>>> They are not 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.
No, I only need to distinguish between Identifiers as the yare defined
in javascript and all the possible other interpretations of the term
that may be employed in other contexts. For which I need nothing more
than a precise definition of what an Identifier is in relation to
javascript, as provided by the specification.
>>> and they are not becoming identifiers out of being processed
>>> by this rules.
>>
>> 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*.
The place where these terms are used "in the *language*", as you put it,
is in the specification for the language.
> Can you make an effort and to get
> out from the irrelevant lower level matters?
I already have little interest in "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.
True, but then your point would be?
> 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.
There is a delusion here, but it is in your perception. The parsing of
the language is defined in the specification, and is relevant to the
issues here, but at no point has anything said here by anyone but you
involved "C/C++ parser rules". Javascript's parsing rules are
independent of any particular language used to implement javascript.
Ricahrd.
John G Harris
<snip>
>The identifier foo identifies a variable foo in the context of Global
>or function scope.
In a 'with' statement it identifies a property if the 'with' object has
a property with that name.
>In an implicit object constructor if used in the
>position of the property name it identifies
...
<snip>
>Another option - other than claiming your quoted statement be a lore
>from the Alpha Centauri programming school :) - is to stop writing
>"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
>capitalization and proper reference so then make it clear that you are
>not talking about a programming entity but about a charcode sequence
>defined by such and such formal criteria. Then:
You need glasses. I never *started* using 'identifier' when I meant
'Identifier'.
When did source files stop containing 'programming entities' ?
<snip>
>1) What is the difference between a Harris' "parsing stage ECMA 262
>3rd.ed. Identifier" on and an "identifier" in the casual programming
>sense in the program itself.
<snip>
We've been trying to work out what you mean when you write identifier.
You seem to change your meaning every other paragraph.
John
--
John Harris
VK
> On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:
>
> <snip>
>
> >The identifier foo identifies a variable foo in the context of Global
> >or function scope.
>
> In a 'with' statement it identifies a property if the 'with' object has
> a property with that name.
Let's not talk about all things at once. Right now we are looking at
an object constructor literal.
> >In an implicit object constructor if used in the
> >position of the property name it identifies
>
> ...
>
> <snip>
So I understand that besides the suggested definition extension above
the first definition is what you were trying to say. Well, I only can
repeat that "this is an extremely weird approach of course but at
least it has some sense within the human programming science". I still
do not understand why you are considering this approach - not used
anywhere outside this group and actually nowhere outside of this
thread - as something definitely and only right one.
> >Another option - other than claiming your quoted statement be a lore
> >from the Alpha Centauri programming school :) - is to stop writing
> >"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
> >capitalization and proper reference so then make it clear that you are
> >not talking about a programming entity but about a charcode sequence
> >defined by such and such formal criteria. Then:
>
> You need glasses. I never *started* using 'identifier' when I meant
> 'Identifier'.
Possibly not you, sorry then. It was a bounch of exited posts in here
with "identifier", "Identifier" mixed in all different ways.
> When did source files stop containing 'programming entities' ?
at the moment it's going through the parser.
> <snip>>1) What is the difference between a Harris' "parsing stage ECMA 262
> >3rd.ed. Identifier" on and an "identifier" in the casual programming
> >sense in the program itself.
>
> <snip>
>
> We've been trying to work out what you mean when you write identifier.
> You seem to change your meaning every other paragraph.
That's rather stupid to claim. All the way though I was very explicit
by what does "identifier" mean in the programming (not in some "VK's
thesaurus" or so): with 3rd source definitions, with samples of
identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
execution stage. You just need to follow the thread.
John G Harris
>On Nov 2, 10:56�pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>> On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:
>>
>> � <snip>
>>
>> >The identifier foo identifies a variable foo in the context of Global
>> >or function scope.
>>
>> In a 'with' statement it identifies a property if the 'with' object has
>> a property with that name.
>
>Let's not talk about all things at once. Right now we are looking at
>an object constructor literal.
But you're the one who is talking about identifiers naming variables. I
just added another case, where it names a property.
>> >In an implicit object constructor if used in the
>> >position of the property name it identifies
<snip>
>All the way though I was very explicit
>by what does "identifier" mean in the programming (not in some "VK's
>thesaurus" or so): with 3rd source definitions, with samples of
>identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
>execution stage. You just need to follow the thread.
In all the mainstream languages 'identifier' means any sequence of
characters in a source file that matches the collection of syntax rules
named either 'Identifier' or 'identifier'.
In database technology 'identifier' has a more specific and technical
meaning.
John
--
John Harris
VK
> In all the mainstream languages 'identifier' means any sequence of
> characters in a source file that matches the collection of syntax rules
> named either 'Identifier' or 'identifier'.
It is not a "mainstream" definition of identifiers. It is, as I said
earlier, some aggressive mechanicism with the functional part of the
language abruptly removed. If it is indeed not some of your own
definitions but a CS school definition I am really curious where does/
did it reside. I couldn't find such even in Berserkeley which is
always a place to look for some new weird stuff :)
John G Harris
Well, there's Wikipedia, under 'identifier'.
And there's the Pascal report by Jensen and Wirth.
And there's the C++ standard (which you won't have seen because it costs
money). "An identifier is an arbitrarily long sequence of letters and
digits" ...
And there's the O'Reilly book "C# Essentials". "An identifier must be a
whole word" ...
John
--
John Harris
Richard Cornford
> On Thu, 5 Nov 2009 at 09:23:44, in comp.lang.javascript, VK wrote:
>>John G Harris wrote:
>>> In all the mainstream languages 'identifier' means any sequence of
>>> characters in a source file that matches the collection of syntax
>>> rules named either 'Identifier' or 'identifier'.
>>
>>It is not a "mainstream" definition of identifiers. It is, as I said
>>earlier, some aggressive mechanicism with the functional part of the
>>language abruptly removed. If it is indeed not some of your own
>>definitions but a CS school definition I am really curious where does/
>>did it reside. I couldn't find such even in Berserkeley which is
>>always a place to look for some new weird stuff :)
>
> Well, there's Wikipedia, under 'identifier'.
The Wikiepedia page:-
<URL: http://en.wikipedia.org/wiki/Identifier >
- includes, under the hading "Advantages of the application" the
statment "Since the uniqueness of an identifier, the confusions about
the various descriptions on one substance, one item, one topic, or one
object can be cleared". Which is the sort of VKesque non-sentence that
undermines credabilty.
Richard.