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

Herby Vojčík herby at
Sat Jan 21 13:56:39 PST 2012

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. 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 *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).

>> The solution that spring to mind is straightforward the use of
>> now-orphaned private keyword for it seems just right. I only proposed
>> (as of actual situation, not as revival of old strawman; as a shortcut
>> for actual calling name.create() at the start of the program or
>> simulated in compilation phase) to use private to declare such
>> identifiers, each pre-filled with name.create() once, with block
>> visibility.
>> For foo. at bar it is very convenient. I really believe big percentage of
>> name.create() is of this sort. Not going against
>> harmony:private_name_objects, just add a convenient use.
> I quite agree. Requiring Name.create() or new Name() all over is a drag.
> We should keep honing in on more convenient private name object
> binding-declaration and binding-use syntax.
> /be


More information about the es-discuss mailing list