Private Slots

Brendan Eich brendan at
Tue Jan 15 13:07:16 PST 2013

Very fair response -- thanks. I want to add praise for Kevin, he asks 
the right questions, especially the one to which I replied "hold that 

 > Maybe it's worth it, I don't know.  That's the whole point:  I don't 
know.  And when in doubt...

We certainly did leave out something in doubt: declarative private 
@-name syntax. But private symbols (vs. unique ones) seem to be worth 
their weight for the better performance model, as Tom notes.


Tom Van Cutsem wrote:
> In defense of Kevin, I too would argue that private symbols add 
> complexity to the object model.
> That doesn't mean I'm arguing in favor of removing private symbols, 
> just noting that we do pay a complexity price.
> We should not deny that with the addition of private symbols, we had 
> to reconsider every existing ES5 operation to see whether it needed to 
> be adjusted so that it does not leak private symbols. We happen to be 
> lucky that Object.keys and Object.freeze can be thought of as using 
> Object.getOwnPropertyNames, so adjusting gOPN (and the Proxy API) 
> closed all leaks identified thus far. Going forward from here, we need 
> to continue to be vigilant about private symbol leaks.
> I also think Kevin is making the fair point that for the 99% use case, 
> unique symbols are sufficient. For software engineering purposes, they 
> provide good enough encapsulation. "private" in Java is not really 
> private due to java.lang.reflect, but that doesn't stop people using 
> it to express encapsulation.
> Since Kevin is merely asking for a good explanation of why private 
> symbols are "in", I would say that it's because TC39 explicitly wanted 
> symbols to be usable for high-integrity encapsulation scenarios.
> Kevin's reply to that is "if the use case is high-integrity 
> encapsulation, why aren't WeakMaps sufficient?"
> The response to that is: WeakMaps add more boilerplate and more 
> overhead. I don't think the WeakMap boilerplate overhead is an actual 
> issue for people writing defensive code (such code already has to go 
> so out-of-its-way, e.g. by using early-bound primordials, I think it 
> can deal with WeakMaps). The performance argument still stands though.
> Cheers,
> Tom
> 2013/1/15 David Bruant <bruant.d at <mailto:bruant.d at>>
>     Le 15/01/2013 17:16, Kevin Smith a écrit :
>>         The variable was called "s" standing for secret. The example
>>         I gave was dummy, but examples in the wild are legion. Take
>>         your favorite node library. Anytime it defines a _property,
>>         this is where there should be a private name.
>>     Again, that's arguable.  Certainly it would be better expressed
>>     with a symbol.  But private?  Are most node authors attempting to
>>     write "secure" code?  Of course not!
>     People writing Java code do use the private keyword. I think if
>     encapsulation wasn't that hard to achieve, people would do it. I'm
>     looking forward to see people use classes and modules without
>     putting more effort that they do currently and yet write more
>     secure code by default.
>>     Node (by itself) does not provide a secure environment for
>>     untrusted code.
>     What I know of Node makes me think it's not that much worse than
>     any other platform and from experience, at least much better than
>     anything I've played wit in PHP.
>>         One of the goal was that no one had access to the "s" part of
>>         the state. You need private symbols for that.
>>     But why?  Where is this strict runtime privacy requirement coming
>>     from?  What I'm not understanding is the larger context in which
>>     mutually untrusting code supposedly shares raw (non-proxied) objects.
>     The reason you can't write code in any blog comment these days is
>     that people have given up on securing untrusted code. Likewise for
>     emails. HTML is used for emails, but scripts aren't executed,
>     because email client (web-based or not) have given up on the idea
>     of securing email code.
>>     Where is the real world code doing this?
>     I think iGoogle does this. Otherwise, close to nowhere because
>     people have given up.
>     My guess is that they have given up because the language does not
>     make easy to sandbox untrusted code. As soon as you have naturally
>     written your code in JavaScript, it's unsafe and it takes a lot of
>     work making it safe. People give up. Private symbols are one tool
>     to lower the barrier to writing code secure by default.
>>     For what applications?  Really, I want to know! : )
>     They do not exist unfortunately. That's a chicken and egg problem.
>     As soon as it'll be easier, people will probably restart thinking
>     of what they want to do with the new tool they have in hand.
>     That's what happened when JS engines got faster. Developers didn't
>     stay still happy that their websites just got faster. Websites
>     just started to get more and more JS.
>>     In "Crockfordian" design, "name encapsulation" and "security
>>     encapsulation" are indistinguishable.  But unique symbols address
>>     "name encapsulation".  Is there really a need to address
>>     "security encapsulation" at the *object property level*?
>     It seems that it lowers the barrier to writing secure code by
>     default. If that's the only thing to gain, I'll take it.
>>         Thinking more about the loading third-party code, I guess
>>         it's technically doable to do without private names. It comes
>>         to the cost of creating proxies doing the encapsulation for
>>         you. You provide a blacklist of properties that must not be
>>         reflected and the third party never sees them... In essence,
>>         you're listing the private properties and the proxy does the
>>         book keeping (details about non-configurability aside).
>>     Sure - and approaches like this (or simpler - people are clever!)
>>     can be factored away into a neat library, without having to mess
>>     with the underlying object model.
>>     ES6 provides WeakMaps and Proxies.  Why not see what people do
>>     with those before introducing private slots?
>     I wouldn't be opposed to that, but that's just my opinion. Still,
>     private symbols allow property-like syntax. I haven't followed the
>     latest developments of how classes and private symbols interact,
>     but I'm not too worried it goes well. Assuming it does, it makes
>     it easy for people to use actually private properties in their
>     code, lowering the barrier to writing well-encapsulated code.
>     David
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list