Security Demands Simplicity (was: Private Slots)

David Bruant bruant.d at
Thu Jan 17 10:02:43 PST 2013

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.

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.


More information about the es-discuss mailing list