shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich brendan at
Sat Jan 21 14:11:15 PST 2012

> Herby Vojčík <mailto:herby at>
> January 21, 2012 1:56 PM
> Brendan Eich wrote:
>>> Herby Vojčík <mailto:herby at>
>>> January 21, 2012 1:33 PM
>>> Brendan Eich wrote:
>>>> The last really was too much for some folks. It makes the meaning 
>>>> of an
>>>> identifier after . or before : in an object literal depend on a 
>>>> binding
>>>> declaration, possibly far above.
>>> Thank you. I did not know of these. The problem in the third one (and
>>> the solution) are really crazy... I would do the early error if there
>>> would be a clash (akin to double let).
>> The way to resolve the two-lexical-binding-chains issue for private
>> declarations is not to overload . (member expression; also : in object
>> literals), by requiring @ instead:
>> private foo;
>> @foo = bar; // this-relative private foo
>> return @foo === other. at foo;
>> return {@foo: bar};
> This helps a lot, but there still _is_ (I only proposed a convenient 
> shortcut, not some magic special names for private names) an 
> identifier foo having that private name in its value.

This was not decided, as far as I know. There are two choices:

1. "private foo;" defines a lexical binding used to denote the private 
name object, as well as after @ to use it to access a property in an object.

2. Rather, the *only* places foo would be allowed after "private foo;" 
above are those after an @. IOW it would be fine to use "let foo = 42;" 
and "private foo;" without conflict. Some further syntax, a la the old proposal (obsoleted in terms of # now), would be required to 
reflect foo from lexical-to-the-right-of-@ space into a first-class 
private name object reference.

> So it _would_ clash if foo was defined in code. But I believe that 
> this can be solved by applying analogies from let, var, scopes, 
> shadowing etc. all that machinery.

I'm not sure what you mean. Choice (1) above allows shadowing. Choice 
(2) doesn't have any conflict.
>> I *think* we may be pretty close to consensus on this, but I'm not sure.
>> Not in ES6 at this point.
> Well, I am pretty hoping for this. It makes thing much more 
> straightforward (when compared to private in actual class proposal 
> with private store etc. - private names work and are generic).

I may be overoptimistic about consensus. The choice (1) vs. (2) remains 
open, IIRC.


More information about the es-discuss mailing list