Not a mutable store. The interned symbols table is.
Can we get back to the somewhat pressing problem of @iterator vs.
'iterator' vs. Symbol.intern('iterator')? Firefox implements 'iterator'
currently, happy to change, no need to rush, but the trade-offs are
pretty clear.
Kevin Smith pointed out the problem for libraries trying to work
cross-frame and cross-version. Tab was +1 on Symbol.intern. I am too,
since the conflict between unique symbols and cross-frame singleston
symbols is irreducible. The alternative of a singleton module shared
among several realms is unproposed, unclear, and overkill for the
@iterator-cross-frame problem.
Anyone have a better idea?
/be
Allen Wirfs-Brock wrote:
The private name proposal included the possibility of attaching a
string value to a symbol when it is created. The string could be used
in debug output (toString) for the symbol.
"Mark S. Miller" <[email protected]> wrote:
It depends what you mean by "associating". What do you have in mind?
On Thu, Oct 4, 2012 at 1:18 PM, Allen Wirfs-Brock
<[email protected] <mailto:[email protected]>> wrote:
Presumably, this concern would also apply to associating
programmer supplied debug info with symbols
"Mark S. Miller" <[email protected] <mailto:[email protected]>>
wrote:
On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock
<[email protected] <mailto:[email protected]>> wrote:
Note that in most cases, you want to look up an already
interned symbol name rather than intern a new one.
One of the beautiful things about interning is that it is a pure
function, and so does not provide a communications channel. If one
frame could test whether some other frame somewhere had already
interned a given name, you'd have an unpluggable cross-frame
communications channel.
--
Cheers,
--MarkM
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
