About private names

Dean Landolt dean at deanlandolt.com
Sun Mar 20 16:20:45 PDT 2011


On Sun, Mar 20, 2011 at 6:21 PM, Allen Wirfs-Brock <allen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110320/2d22d9f0/attachment-0001.html>


More information about the es-discuss mailing list