On Tue, Jan 22, 2013 at 8:13 AM, Brandon Benvie <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
