Implicit object constructor misinterpretation

Discussion in 'Javascript' started by VK, Oct 24, 2009.

  1. VK

    VK Guest

    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

    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.
    VK, Oct 24, 2009
    #1
    1. Advertising

  2. 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.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.)
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #2
    1. Advertising

  3. VK

    Evertjan. Guest

    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.lang.javascript/msg/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)
    Evertjan., Oct 24, 2009
    #3
  4. VK

    VK Guest

    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.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.
    VK, Oct 24, 2009
    #4
  5. VK

    VK Guest

    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 ;)
    VK, Oct 24, 2009
    #5
  6. 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.)
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #6
  7. 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.)
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #7
  8. VK

    Evertjan. Guest

    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)
    Evertjan., Oct 24, 2009
    #8
  9. 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
    John G Harris, Oct 24, 2009
    #9
  10. VK

    VK Guest

    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-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.
    VK, Oct 24, 2009
    #10
  11. VK

    VK Guest

    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.
    VK, Oct 24, 2009
    #11
  12. 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
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #12
  13. 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
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #13
  14. 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
    Gregor Kofler, Oct 24, 2009
    #14
  15. VK

    VK Guest

    VK, Oct 24, 2009
    #15
  16. 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
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #16
  17. 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$>
    Thomas 'PointedEars' Lahn, Oct 24, 2009
    #17
  18. VK

    VK Guest

    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
    VK, Oct 24, 2009
    #18
  19. VK

    VK Guest

    VK, Oct 24, 2009
    #19
  20. 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'
    Lasse Reichstein Nielsen, Oct 24, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sb
    Replies:
    10
    Views:
    4,607
    Andre Heinen
    Feb 25, 2004
  2. flopbucket
    Replies:
    1
    Views:
    496
    Tom Widmer
    Jun 26, 2006
  3. Alex Vinokur
    Replies:
    9
    Views:
    410
    Thomas J. Gritzan
    Aug 10, 2006
  4. Jess
    Replies:
    3
    Views:
    298
    Robert Bauck Hamar
    Jun 14, 2007
  5. Generic Usenet Account
    Replies:
    10
    Views:
    2,221
Loading...

Share This Page