Private Slots

David Bruant bruant.d at
Tue Jan 15 00:47:39 PST 2013

Le 14/01/2013 17:45, Kevin Smith a écrit :
>     No boilerplate, no additional runtime costs than what's necessary.
> Arguably, all of those examples could be addressed by unique symbols. 
>  Where is the need for strong runtime enforcement of encapsulation?
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.
One of the goal was that no one had access to the "s" part of the state. 
You need private symbols for that.

>         I would personally like to see answers to the following questions:
>         - Do private slots enable applications that would otherwise be
>         impossible?
>     I guess applications where you need memory for your actual content
>     and not memory to compensate the lack of language expressiveness.
>     I have no real idea of how much can be saved in terms of memory
>     between the 3 snippets I've shared with millions of C instances.
> Private symbols are not necessary for this.  Unique symbols work just 
> fine.
The implicit requirement was that only trusted parties were expected to 
have access to the "s" variable or equivalent in other examples. Unique 
symbols are enumerated, so do not do the job.

>         - What are some examples of real-world applications where the
>         runtime security of private slots is necessary?
>     It really depends on what you mean by "necessary". As far as I'm
>     concerned, it'd be all application using third-party code and a
>     lot of websites embed a Google Analytics script, so that would be
>     a lot of them (looking forward to the day GA is being hacked by
>     the way :-) )
> I want to see more along these lines.  What is the security model for 
> "loading third-party" code and in what way do private slots help?
I'm realizing now that I may be off-topic. I'm not that interested 
whether it's a new type of slot with the non-freezability property. I 
only care that it's private (non-enumerable with Object.getOwnPropertyNames)

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). It'd be more appropriate to define this private properties 
directly on the object if there is a commonality to what you wish 
keeping to your self when considering sharing the object.

I don't know whether this justifies a new type of slot. Brendan's "none 
of your business" argument has a point. Additionally, if you do not have 
access to a private symbol, why should you be provided by default the 
right to change related private property descriptors?

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

More information about the es-discuss mailing list