Ducks, Rabbits, and Privacy

Brandon Benvie brandon at
Tue Jan 22 08:13:28 PST 2013

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. 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 <javascript:;>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list