Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Implicit object constructor misinterpretation

Reply
Thread Tools

Implicit object constructor misinterpretation

 
 
VK
Guest
Posts: n/a
 
      10-24-2009
John G Harris wrote:
> The man who invented the language said it must be like that. Get used to
> it.
>
> If you can't, find another language.


I wouldn't put the strict equality sign between what the Man did and
what others (ECMA freelancers) managed to write about it. Say it was
obvious for the Man that in case
(function f() {
})()
function f being created and added to the namespace. It was so for
him, for NN2.x-4.x, for Eric Lipper porting it to IE. Only much later
during the "hand-pointer" opposition stage some read out an
alternative meaning from ECMA to make IE wrong in yet another small
but pleasurable point.

On the topic and if you manage to fight over the regular "get VK!"
instincts than you see that:

{
a: "a",
b: "b"
}
is interpreted as a block with a and b label literals.

{
a: "a",
"b": "b"
}
is interpreted as a block with a and b label literals where b is
illegal as we cannot use string value instead of literal so syntax
error.

var obj = {
a: "a",
"b": "b"
}
creates the necessary interpretation context so the right part is
treated as an object constructor and the automatic quoting gets on, so
we may quote the keys, do not quote them or do quote them zebra-style
or whatever. Even if the very first key is not quoted, it is still
interpreted as key string value, because the "interpretation decision"
is being made before that.

var obj = {
a: "a",
"default": "b"
}
absolutely the same as before, the "interpretation decision" is being
made before entering so it is already decided that it is an object
constructor and not a block of statements, so it is irrelevant that
the first key is not quoted: the quotes will be added automatically.

var obj = {
a: "a",
default: "b"
}
the "interpretation decision" is being made before entering so it is
already decided that it is an object constructor and not a block of
statements, so it is irrelevant that the first key is not quoted: the
quotes will be added automatically;
THEN the system meets [default] chars sequence which corresponds to
one of reserved words in the parser list AND it changes its own
previous decision: now no, it is not a constructor but a block of
statements with the second one preceded by an illegal label literal.

Some might find it very logical. I am definitely not in that club.

 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      10-24-2009
VK wrote:

> John G Harris wrote:
>> The man who invented the language said it must be like that. Get used to
>> it.
>>
>> If you can't, find another language.

>
> I wouldn't put the strict equality sign between what the Man did and
> what others (ECMA freelancers) managed to write about it.


Brendan Eich is at least in the contributor's list for all three Editions of
the ECMAScript Language Specification, and its apparently upcoming fifth
Edition. You make it look instead as if the ECMAScript standardization
process had/has nothing to do with him. That is extremely unfair of you
given his ongoing efforts to improve the language, and quite presumptuous
given that you are using it to justify your ongoing fantasies about how
things would be. Go away.


PointeddEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      10-24-2009
VK wrote:

> Thomas 'PointedEars' Lahn really killed me recently after years of
> quoting to death different papers and then not knowing that delete
> this.val is not allowed at least in IE.


Stop perverting the facts. It is apparently not allowed if `this' refers to
the ECMAScript Global object *only* in JScript so far -- a clear *bug* (that
no reasonable implementation is going to produce). In all other cases proof
that it does not work has yet to be given.

> For me it's like if someone knows by heart all von Clausewitz and all
> field regulations yet not able to reload his own rifle


Obviously it did not cross your puny malfunctioning replacement of a mind
that I never needed to delete any properties of the ECMAScript Global Object
in the first place (guess why).


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
 
Reply With Quote
 
Gregor Kofler
Guest
Posts: n/a
 
      10-24-2009
VK meinte:

[crap snipped]

> I honestly don't give a damn what ECMA says on it, it sucks even
> carved somewhere on a stone. With this and the preceding label vs key
> issue the safe coding policy will be changed: it will be required in
> the office and from subcontractors to use explicit quoting of object
> key values and do not ever relay on the implicit one. The group
> readers may or may not account this coding advise.


For the less perceptive (like you): "default" is a reserved word in JS.

Gregor


--
http://www.gregorkofler.com
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-24-2009
Gregor Kofler wrote:
> For the less perceptive (like you): "default" is a reserved word in JS.


The same pre-requisite asked to distinguish between literals and
string values. Se also
http://groups.google.com/group/comp....0cb6ffc451e69b

 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      10-24-2009
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"?

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
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      10-24-2009
VK wrote:

> 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$>
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-24-2009
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]"

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

 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-24-2009
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/mozil...7669ddd693937a


 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      10-24-2009
VK <> writes:

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A constructor calling another constructor (default constructor)? Generic Usenet Account C++ 10 11-28-2007 04:12 AM
implicit conversion through constructor Jess C++ 3 06-14-2007 02:40 PM
Implicit default constructor is not called Alex Vinokur C++ 9 08-10-2006 04:04 AM
Implicit conversion constructor with template classes flopbucket C++ 1 06-26-2006 10:29 AM
implicit constructor declaration (user annoyed) sb C++ 10 02-25-2004 06:42 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57