> Symbols (private or public, don't forget the latter) are crucial to ES6
> and not going away :-|.
>
No problem here with public symbols! They provide collision-free property
naming without changing the underlying object model. Woot!
But when I ask for use cases for private symbols, I get answers that in
affect say: because they make it easier to create "private" data and
methods. Well, that just begs the question (h.t. @domenic ; )! Why is
this strict "privacy" so important for object property access?
I can't for the life of me imagine that it would be a good idea to have two
mutually untrusting bodies of code executing in the same environment,
without the mediation of some strict sandboxing infrastructure presiding
over them, along with strict guidelines limiting their communication.
Having mutually untrusting code bases, managing their own security, and
passing around objects adorned with private data and methods seems to me to
be a recipe for disaster.
Unique symbols provide a sufficient encapsulation mechanism for API design
by making it inconvenient to access symbol-named properties without the
symbol. But private symbols go beyond this and create a *new kind of
slot*. Is this extension to the object model really necessary? Is it
necessary for ES6?
We are conflating property access (an API issue) with security, and the
ramifications are bleeding out into the proxy design and into the nature of
"freezing". This smells like a separation of concerns issue to me.
WeakMaps address the security use case. Unique symbols address the API use
case. This is a clean separation of concerns and is easy to understand.
(Apologies for being a bit of a gadfly on this...)
{ Kevin }
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
