Symbols, Protocols, Frames, and Versioning

Allen Wirfs-Brock allen at
Thu Oct 4 11:41:56 PDT 2012

On Oct 4, 2012, at 11:29 AM, Brendan Eich wrote:

> Tab Atkins Jr. wrote:
>> It might be useful to expose this functionality with a more obvious
>> name, to underscore that you lose the secrecy/unforgability.
>> Symbol.public()?
> We are mooting public as the keyword for non-private but unique symbols, so that's ambiguous. ReallyPublic? :-P We want to capture the singleton sharing, and 'intern' is the jargon word to use. For the jargon-disabled, I'm not sure what to use, but perhaps teaching people about intern'ing is better than using some long Java-esque name.


Note that in most cases, you want to look up an already interned symbol name rather than intern a new one.  If the lookup falls back to creating, typos will tend to get hidden.

BTW, other than as a place to hang this function, I still don't see why we need a named Symbol constructor. 

symbol @foo;


symbol @foo = new Symbol.

mean exactly the same thing, assuming Symbol has its default binding.

I just don't  see what value we get from cluttering the name spaces with a built-in constructor that doesn't add any new functionality.


More information about the es-discuss mailing list