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 > [email protected] <javascript:;> > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
