Private Slots

Kevin Smith khs4473 at
Tue Jan 15 08:16:56 PST 2013

> 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!  Node (by itself) does not provide a secure
environment for untrusted code.

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.

Where is the real world code doing this?  For what applications?  Really, I
want to know! : )

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*?

> 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?

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list