On Jul 29, 2013, at 5:26 AM, Kevin Smith <[email protected]> wrote:
> The defining feature of symbols is that they are unguessable, but this
> feature is useless in the context of "unique symbols", since one can always
> just get to the symbol by property inspection. As such, symbols appear to
> provide no benefit over strings for this use case.
The defining feature of symbols is that they are default-encapsulated. As in:
{ [sym]: value }
// or
obj[sym] = value
does not make an object with properties that leak out to any other
non-meta-level code. That is, all the commonly used MOP interactions are
oblivious to its existence. If you want to use a very specialized function that
does exposé it, then you're almost certainly doing it serious introspective
reasons, like debugging or something.
{ [stringSym]: value }
// or
obj[stringSym] = value
leaks to Object.keys and for-in, which are very commonly used operations and
will get used in conjunction with getting and setting. That destroys the
encapsulation component of Symbols, which I argue is one of (if not the
primary) benefit of Symbols.
> In fact, unique strings provide a useful feature that symbols do not: they
> need not be associated with any runtime execution context. We can define a
> well-known unique string and share it across realm boundaries. We can also
> share these keys across version boundaries, such that many versions of a
> library can recognize the same key.
If this benefit were desired then it's possible to make it so there's a way to
construct a symbol using a given GUID such that the same Symbol would be
returned no matter where you asked for it from. With caveats, it could be
implemented in library code (though it would be preferential for it to be
specified and commonly available).
Symbol.fromGUID(...)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
