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

Herby Vojčík herby at
Wed Jan 25 09:35:48 PST 2012

(resend to list; forgot)

Sorry for late answer, but I lost mails from Monday 4:30-17:30 CET, so I 
waited for them to appear in .gz archive to download and import them to 
mu inbox again.

Answers below.

Brendan Eich wrote:
>> Herby Voj??k<mailto:herby at>
>> January 22, 2012 12:34 PM
>> Brendan Eich wrote:
>>> I suspect your very complicated translation with __prvTable__ etc. is
>>> intended to hoist private somehow, once per declaration in source
>>> rather
>>> than once per evaluation of declaration. That's too restrictive, since
>> Exactly. By design.
> For classes, we have agreed on class-private, rather than
> instance-private, instance variables. However you don't need such a

Of course, classes were the primary concern in that proposal of mine. 
But I hate special cases. Since it seems you really want private foo to 
be shortcut for const foo = Name.create(), I can go with it ...

> complex desugaring for classes, and "private x;" not in a class should
> be evaluated, not hoisted into singleton-hood somehow.
> class Point { ... private x, y; ... } // ignore details of whether in
> constructor or class body
> should desugar roughly to
> let Point = do { private x, y; class Point { ... ... } };

... by generalizing it* so that:
- if private foo appears in code, it is shortcut for const foo = 
- if private appears in object literal, it is desugared to
[assignment = ] do { private foo; expression_using_a_literal; }

* I am treating class block as an object literal. I will always try to 
make it so that class is in fact an operator on object literal. I am not 
good with explaining why it is good, though I am trying. I see real 
(future-friendly) reason for not having any kind of special block for class.

> so as to achieve the class-private instance variable semantics wanted.

If the class is created as a class expression inside some function or 
method, the private name is always different. Yes, the class is also 
always different. May lead to little confusion, but nothing critical. 
Maybe it is good to raise awareness to this case somewhere.

> This does suggest that putting the private declarations in constructor
> is a mistake, since they would seem to be generated once per
> construction (instance), not once per class (as class-private wants).


> /be


More information about the es-discuss mailing list