Ducks, Rabbits, and Privacy

Mark S. Miller erights at
Tue Jan 22 09:49:57 PST 2013

On Tue, Jan 22, 2013 at 8:13 AM, Brandon Benvie
<brandon at> wrote:
> I also agree with everything that Nathan said.
> To clarify, there's Symbols and then there's private Symbols. I don't think
> anyone in TC39 is suggesting the removal of Symbols in general. Private
> Symbols have a much more specific set of uses cases than do just Symbols in
> general, and regular Symbols will accomplish the goal of encapsulation.

That's like saying that ES3 "var" accomplishes the goal of lexical
scoping. Never mind that it's broken; it seems to work for most code,
and we don't care otherwise.

We can avoid needless terminological debate by explaining unique
symbols as what they are -- a way to avoid needless name collisions
when naming properties.

> Regular symbols are only enumerated by a new ES6 function and are unique.
> Currently, the only difference between a normal symbol and a private Symbol
> is that private symbols are not enumerated by getOwnKeys and they are slated
> to eventually be awkward to use with proxies. Otherwise a normal (aka
> Unique) Symbol works exactly the same.
> On Tuesday, January 22, 2013, Domenic Denicola wrote:
>> > The fact that ES built-ins' methods are defined on the prototype **and**
>> > have access to private data seems to indicate that the ideal model would
>> > allow both. WeakMaps do, to a degree, permit both, but it's just a hack. If
>> > it wasn't, the ES spec itself would describe built-ins' private data as
>> > living outside the object itself in a WeakMap. The spec doesn't do that
>> > because it's unnatural. Private symbols provide a mechanism for tying
>> > private data to objects in the most natural and reasonable way.
>> +1 to this and everything else Nathan has said. Watching all this intense
>> back and forth, there are a lot of good points, some of which almost
>> convince me that weak maps are sufficient and private symbols are
>> unnecessary. But when I step back for even a minute, as a developer private
>> symbols are exactly what I want, and weak maps are an un-ergonomic hack.
>> To put it another way, private symbols have been very easy for me to
>> explain to other developers. I simply give them the prototype example with
>> unsecured underscored properties, then the closure example with bad memory
>> and performance characteristics, then show them the private symbol version
>> which solves both problems in a pretty elegant way with syntax that makes
>> perfect intuitive sense. They provide a method of storing private state on
>> the object in a way that fits with the object model we know and love, as
>> exemplified by the many [[InternalProperty]]s of the spec or the
>> underscored-properties of ES5-era prototypal JavaScript.
>> So I don't have any overwhelming technical or security arguments, but just
>> from a developer ergonomics and pedagogy perspective, I <3 private symbols
>> and wish I could banish the grim reaper that seems to be hanging over them.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at


More information about the es-discuss mailing list