On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote: [big top-cite snipped -- folks, please try to cut if you can.]
> I think you're missing the distinction. The obj["foo"] example is just a > stand-in for `var foo="foo"; obj[foo]` -- we would all expect the string key > lookup to be the same as obj.foo, and anything less would be a bit > surprising. This is what Andrew was reacting to. I see confusion here in making the name of the var the same as the string contents. Allen's point is valid, I've meditated on it at length: In JS, a plain identifier not after dot is looked up in the scope chain (in Harmony this will be lexical scope only, i.e., all compile time -- typos get early errors). But after dot, an identifier is not looked up early or late in the scope chain, only in the proto chain of the object resulting from evaluating the expression to the left of the dot. Obviously, obj.foo and obj[id] are equivalent currently iff id === "foo". In particular, this equivalence does not apply if id's character sequence does not match the lexical grammar for Identifier. Private names indeed adds indirection, but we already have the public (string-equated) name case: it must be lexically an identifier. The indirection due to the |private id| declaration, block scoped, may be confusing or helpful. The strawman shows examples that can be read both ways. > The relationship between bracketed string lookup and dot lookup is, for now, > very clear and predictable -- private names muddies it up a bit. I wouldn't say "muddle", given the existing "public name must be an identifier, lexically" restriction. The strawman proposes the #.id operator to reify a private name as a value to be used in brackets, or a public name as a string, also usable in brackets. There's no free lunch, so you could claim this whole strawman is too expensive. Compared to what, though? Without this tool, name-mangling has zero integrity. Anyone can step on your prefixed or otherewise mangled name. I encourage folks to read the private names thread from late last year, since we are revisiting the points made then: https://mail.mozilla.org/pipermail/es-discuss/2010-December/ /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
