Security Demands Simplicity (was: Private Slots)

Brandon Benvie brandon at
Thu Jan 17 13:50:53 PST 2013

November's meeting had re-instituted computed property names to compensate
for the dropping @name support to allow for symbols to be used as method
names. AFAICT there's currently no actual way to create a private Symbol in
any active proposals for ES6, however (this was only covered as part of the
@names proposal). Currently `Symbol` only accepts one parameter, and that's
the string label/name for it.

On Thu, Jan 17, 2013 at 4:13 PM, David Bruant <bruant.d at> wrote:

> Le 17/01/2013 19:30, Mark S. Miller a écrit :
>> On Thu, Jan 17, 2013 at 10:02 AM, David Bruant <bruant.d at>
>> wrote:
>>> Le 17/01/2013 18:00, Mark S. Miller a écrit :
>>>> I still have this position on classes. But I no longer buy that
>>>> pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
>>>> used by the expansion of classes-with-private. Just 'cause it's on the
>>>> top of my head, below I use the old representation of one WeakMap per
>>>> class providing access to a record of all the private state. For the
>>>> same reason, I'll use the encapsulation of the Purse example without
>>>> any of the numeric checks.
>>>> class Purse {
>>>>       constructor(private balance) {
>>>>       getBalance() { return balance; }
>>>>       makePurse() { return Purse(0); }
>>>>       deposit(amount, srcPurse) {
>>>>           private(srcPurse).balance -= amount;
>>>>           balance += amount;
>>>>       }
>>>> }
>>>> expansion
>>> I don't understand the need to expand. This is the class syntax. It
>>> creates
>>> a constructor. Instances of this constructor have some behavior and
>>> characteristics described by the class body. If the class body allows to
>>> define something private, implementors will implement that and work very
>>> hard on performance. I don't think implementors will expand before
>>> compiling
>>> and using the class syntax as some sort of macro (implementors are free
>>> to
>>> tell I'm wrong here).
>>> Assuming I'm right, what it expands to exactly does not matter much,
>>> whether
>>> it's private name or weakmaps or whatever else.
>> Regarding what I actually said, you're right. I am being unbelievable
>> confusing this morning. After that sleepless night, I should probably
>> wait till I'm rested before posting again. Foolishly perhaps, I'll try
>> to answer anyway.
>> 1) It remains useful to define the semantics of classes by expansion.
>> Then one can reason about classes by reasoning about the expansion.
>> This is especially helpful for automated tools. The semantics had then
>> better be faithful to the explanatory expansion.
>> 2) Until ES7 provides private
> I may have missed something. In the harmony proposal on the wiki [1] (is
> the wiki down? I'm looking at google's cache), I see that syntax for
> private properties is in the proposal and nothing suggests it's postpone
> until ES7. I see in recent notes that the @-syntax isn't fully agreed upon,
> but that's where I'm at. Is there no private syntax at all for classes in
> ES6?
>  there will be transpilers that provide actual privacy by other means.
> What syntax and semantics will these transpilers use if TC39 doesn't reach
> an agreement?
>  3) Most important, and most unsaid by my previous email: In ES6, since
>> there's no built-in class/object privacy mechanism, ES6 programmers in
>> general and ES6 class programmers specifically have to achieve real
>> privacy by other means -- by engaging in some pattern using other
>> constructs. Previous conversations assumed that these patterns would
>> be expressed in terms of private symbols. Absent private symbols, the
>> pattern shown by my expansion above, as painful as it is, is what will
>> be expressed manually. By the time ES7 rolls out, there will be a lot
>> of that code.
> People who care will use a transpiler (and I personally don't care if the
> generated code is slightly slower than what it could be natively or ugly).
> People who don't care about privacy will go on with their lives writing
> JavaScript as they do in ES5.
> That's an ephemeral problem in my opinion and isn't the "most important"
> point. Am I underestimating it?
> David
> [1]**doku.php?id=harmony:classes<>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list