> 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
