Private Slots

Kevin Smith khs4473 at gmail.com
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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130115/ead005c6/attachment.html>


More information about the es-discuss mailing list