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" <erig...@google.com> 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
<al...@wirfs-brock.com <mailto:al...@wirfs-brock.com>> wrote:
Presumably, this concern would also apply to associating
programmer supplied debug info with symbols
"Mark S. Miller" <erig...@google.com <mailto:erig...@google.com>>
wrote:
On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock
<al...@wirfs-brock.com <mailto:al...@wirfs-brock.com>> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
