Security Demands Simplicity (was: Private Slots)

Mark S. Miller erights at
Thu Jan 17 10:30:14 PST 2013

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 :
>> However, after the "Private Slots" thread, I spent a sleepless night
>> chewing on getting rid of private symbols.
> Happens to me so often :-)
>> I now think we should.
>> Going back to my earlier
>> On Wed, Jan 16, 2013 at 12:37 PM, Mark S. Miller <erights at>
>> wrote:
>>> My position on private symbols.
>>> My position on classes is and has always been that classes are worth
>>> introducing into the language *only* if they give us, or can be used
>>> with, an affordable means for true object encapsulation. Assuming
>>> Allen is right about what actual implementors will do (which I find
>>> plausible) then WeakMaps are not that means.
>> 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, there will be transpilers that provide
actual privacy by other means.

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.

> Now you're only talking about privacy in the context of classes in this
> post. I understand this as assuming private symbols would be only use in
> class or class-like contexts (after referred as "this assumption" or "the
> assumption").
> If that's your assumption, then I agree that if classes have a "private"
> syntax that is efficiently compiled, private symbols can be dropped.
> It has to be noted that if private symbols are dropped, the set of private
> properties is sealed once and for all in the class body. That is, it's not
> possible to add or remove a private property after initialization. (However
> it remains possible to privately attach information to an object with a
> weakmap kept private)
> If "private symbols will be only used in class or class-like contexts" is
> your assumption, let's talk about it. Historically, JavaScript objects have
> been used in both in OO contexts and as maps. This confusion led to some
> bugs (involving __proto__ for instance)
> As I have suggested in another recent post, most of the time, objects in OO
> contexts are pretty stable: they are created with a given set of properties
> which doesn't change. This stability could even be declared statically
> (that's what the class syntax does actually).
> However, for the map use case, it makes sense to add and remove properties
> at runtime.
> ES6 adds actual maps, so objects (especially the ones instanciated after
> class-born constructors) could be legitimately considered as reserved for OO
> contexts.
> That's a reasoning I agree with since I can't think of cases besides classes
> where private symbols would be used and for which weakmaps wouldn't be
> better.
> So I guess I agree with the removal of private symbols given classes have a
> syntax for private properties and no other relevant use case for private
> symbols is found.
> David


More information about the es-discuss mailing list