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

[Brendan Eich]

> Herby Vojčík <mailto:herby at mailbox.sk>
> January 21, 2012 1:33 PM
> Brendan Eich wrote:
>> This was already proposed. See the whole strawman, but in particular
>> these sections:
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration 
>>
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping 
>>
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the_variable_binding_environment 
>>
>>
>>
>> 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};

I *think* we may be pretty close to consensus on this, but I'm not sure. 
Not in ES6 at this point.

> 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