Symbols, Protocols, Frames, and Versioning

Brendan Eich brendan at
Thu Oct 4 14:28:53 PDT 2012

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?


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" <erights at> 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 
> <allen at <mailto:allen at>> wrote:
>     Presumably, this concern would also apply to associating
>     programmer supplied debug info with symbols
>     "Mark S. Miller" <erights at <mailto:erights at>>
>     wrote:
>     On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock
>     <allen at <mailto:allen at>> 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

More information about the es-discuss mailing list