Private Slots

Brendan Eich brendan at
Wed Jan 16 11:36:11 PST 2013

Well stated, respect.

I think you are underweighting the utility of private symbols. The 
counter-argument I want to make is: what if high-integrity privacy (via 
weakmaps as you propose) as a popular practice would take off, but with 
weakmaps there's no optimization (PICs, TI) as there is for property 
access in top engines today, so developers avoid privacy via weakmaps.

They might use unique symbols. Those paths probably optimize for free as 
with string-keyed properties. But what if they just keep on truckin' 
with public string-keyed properties?

This is a weak argument, I admit. It may be that adoption of any kind of 
privacy, weak or strong, is going to be slow and soft, especially 
without syntax (a la TypeScript, which has no-integrity privacy!).

Not throwing in the towel, just wanted to respond with the best 
counter-argument I can make.


Kevin Smith wrote:
> Thank you Mark, for the GC hint proposal:  it matches what was my 
> (admittedly naive) intuition.  And thanks, Allen, for the thorough 
> description of GC issues.  Very helpful!
> Some points, in no particular order:
> - It seems likely to me that the implementation complexity of {private 
> symbols, weakmaps} will be on par with the implementation complexity 
> of {weakmaps with hints}.
> - Reflectivity of all property names is a useful feature that should 
> not be discarded lightly.
> - Simplicity in the object model is an advantage for everyone 
> attempting to reason about objects.
> - Having one kind of symbol is easier to conceptualize than two. 
>  Indeed, private symbols could be an attractive nuisance if they lead 
> developers toward over-securing their abstractions.
> - Unique symbols provide sufficient encapsulation for 
> software-engineering purposes.
> - It is my conjecture that high-integrity privacy will be required by 
> a small fraction of projects (such as SES sandboxing engines), and the 
> developer audience for these features will be "power-users".  In this 
> case, private symbols might be an over-optimization of a corner case 
> (although it's an important corner!).
> - It looks to me like much of the work to make ES6 future compatible 
> with private symbols has already been done.
> - During the ES7 design process, there will be plenty of user 
> experience with weakmaps and proxies to draw from.  This should make 
> the private symbol decision much clearer.
> { Kevin }

More information about the es-discuss mailing list