On Sun, Mar 20, 2011 at 6:21 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> > On Mar 20, 2011, at 12:49 PM, Andrew Dupont wrote: > > OK, you lost me. > > On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote: > > On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote: > > > Right; I think Dean and I are saying that this would be the first time > obj.foo meant something different from obj['foo']. And to ascertain that > those two meant different things, I'd have to go searching through the code > for a `private foo` declaration. > > > With the private name proposal obj.foo and obj.[#.foo] will always mean the > same thing regardless of whether foo is scoped as a private name or as a > regular property name. > > > I'm not comparing `obj.foo` and `obj[#.foo]`; I get that those two are > equivalent for private names. (I don't know what you mean when you say those > are the same for public names, though, because I don't know what > `obj[#.foo]` means in a public context.) > > > From the Private Names Strawman: > The syntactic form is *#.* *IdentifierName*. This may be used as a * > PrimaryExpression* and yields the property name value of the * > IdentifierName*. This may be either a private name value or a string > value, depending upon whether the expression is within the scope of a > private declaration for that *IdentifierName*; > > > > BTW, if you know that a property name is foo, why would you ever code > obj["foo"] instead of obj.foo? > > > The proposal strongly implies that the `private` declaration affects only > "a property name on the right of . or the left of : in an object > initialiser." Does it also affect bracket notation? In other words: > > private foo; > obj.foo = 42; > obj['foo'] === obj.foo; // true or false? > > If the answer is `false`, that's your answer for why I'd ever code > `obj['foo']` instead of `obj.foo`. If the answer is `true`, then that > answers one of the questions I was asking earlier; but it also means that > there's no way to get around the fact that the `private` declaration is > "shadowing" any possible use of a public property name called `foo` in the > same lexical scope. > > > as Sam answered, the answer is false. > > // test if a property name is a private name in the current scope: > if (#'foo==='foo') { > //foo is bound when used as a property name to its default string > value, not a private name value > } else { > //foo has a private name binding > } > > > Yes, I appreciate that if private names existed you might use obj['foo'] to > guarantee you were accessing a string-named property. However, my original > comment was in response to your statement "It would mean a new and > _surprising_ distinction between dot notation and bracket notation." I was > trying to argue (apparently not very effectively) that there was already a > significant distinction between dot notation and bracket notation and that > private name is just building upon that distinction. Without private names > there is no particular reason to say obj['foo'] rather than obj.foo but > there is a very important distinction between obj[foo] and obj.foo. The > private names proposal preserves that distinciton. > 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. The relationship between bracketed string lookup and dot lookup is, for now, very clear and predictable -- private names muddies it up a bit. Perhaps a big bold warning about this is enough to realign developer expectations, I couldn't say. But whether you'd ever do a bracketed string-literal lookup is beside the point.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss