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
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....0101e295265cb5

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.


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

> 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....0101e295265cb5
>
> 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.)
 
Reply With Quote
 
 
 
 
Evertjan.
Guest
Posts: n/a
 
      10-24-2009
VK wrote on 24 okt 2009 in comp.lang.javascript:

> 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....ff0101e295265c
> b5
>
> 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.


"> 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)
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-24-2009
VK wrote:
> > 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....0101e295265cb5

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

> 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
/ObjectInitializer/ production. And the grammar for that
/ObjectInitializer/ 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 mechanical logic that is at work here, and despite two detailed
explanations you are still incapable to get it.


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

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


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.)
 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      10-24-2009
Richard Cornford wrote on 24 okt 2009 in comp.lang.javascript:

>> The writer of Jason knew this already,
>> [that keys should but do not always condone reserved words]
>> it was the reason that he required all keys to be quoted.

>
> But the need in JSON follows from its use with unknowable data sources
> where the character sequences that will end up in the keys are
> unpredictable. For a programmer writing an object literal the character
> sequence that will be the key is known at the point of writing it, and


True, but the reserved word list is crossbrowserly perhaps knowable,
but illogical.

> so knowing the syntax rules for the object literal construct allows them
> to either see when the names they want to use need special handling or
> to question their choice of names. Blanket rules are not necessary in
> that context, and their application risks the "programmers" being drawn
> into a world of chanting sequences of mystical incantations in place of
> understanding what they are doing.
>
> It is interesting to note that JSON not only requires that all the keys
> be quoted, but that they be quoted with the double quote character (as
> opposed to the apostrophe). It is easy to see how such simplifications
> of format ease the string-based processing of the data.


Perhaps ours is not to reason why [cf Alfred Lord Tennyson],
but I wrote it to show the reasoning,
not as a general advice to be followed up.

A parallel is the [ugly?] habit to [] fieldnames in sql strings,
also to preclude possible reserved word errors.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
 
Reply With Quote
 
John G Harris
Guest
Posts: n/a
 
      10-24-2009
On Sat, 24 Oct 2009 at 06:56:27, in comp.lang.javascript, VK wrote:

<snip>
>I honestly don't give a damn what ECMA says on it, it sucks even
>carved somewhere on a stone.

<snip>

The man who invented the language said it must be like that. Get used to
it.

If you can't, find another language.

John
--
John Harris
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-24-2009
Richard Cornford wrote:
> Or just learning the syntax rules. VK claims to have been writing
> javascript for well in excess of 10 years, so his not already being
> familiar with object literal syntax rules is a little incredible (at
> least if the initial claim was regarded as credible).


As this being attributed to VK I do answer:
exactly because I am in the commercial programming since late 1996
with two "wars" behind (the Big One of 1996-1998 and the "religious"
one of 2005-200 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.


 
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