Prev: Are arguments that are objects passed by reference?
Next: FAQ Topic - How do I access a frame's content? (2009-10-25)
From: Richard Cornford on 25 Oct 2009 10:12
VK wrote:
> VK wrote:
>>> Richard Cornford wrote:
>>> For the Fx (ab)normality I am going to ask out of curiosity at
>>> mozilla.dev.tech.js-engine
> Richard Cornford wrote:
>> 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

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.

From: VK on 25 Oct 2009 11:14
To be the most precise about the weird VK's universe which is can/must
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.
From: John G Harris on 25 Oct 2009 11:16
On Sat, 24 Oct 2009 at 10:12:29, in comp.lang.javascript, VK wrote:

<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
From: Thomas 'PointedEars' Lahn on 25 Oct 2009 12:24
VK wrote:

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


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 25 Oct 2009 13:19
VK wrote:

> 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.)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Are arguments that are objects passed by reference?
Next: FAQ Topic - How do I access a frame's content? (2009-10-25)