Private Slots

Brandon Benvie brandon at
Wed Jan 16 11:47:49 PST 2013

To compare the various scenarios, this is what (I believe) it looks like
for SES. In ES5, SES currently censors gOPN I believe, in order to
implement the equivalent of private keys and/or WeakMap. Given an ES6
runtime environment that only supported unique symbols, it would have to
censor getOwnKeys and filter symbols if they were present in a blacklist
Set. Given an ES6 runtime environment with private symbols, SES wouldn't
have to censor either.

On Wednesday, January 16, 2013, Brendan Eich wrote:

> 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.
> /be
> 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 }
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list