Symbols, Protocols, Frames, and Versioning

Brendan Eich brendan at mozilla.com
Thu Oct 4 11:50:28 PDT 2012


Allen Wirfs-Brock wrote:
> 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.
>
> lookup?

Could have, but see below.

> interned?

Need a verb, Senator. (Obscure Doonesbury ref, sorry.)

> 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.

I hope not! Otherwise the typo is going to propagate anyway, especially 
with reverse FQDNs or such awfulness:

   public @iterator = 
Symbol.lookup('org.emca-international.org.es6.iterator');
   if (!@iterator) {
     @iterator = Symbol.intern('org.emca-international.org.es6.iterator');
     // oops...
   }
   // d'oh!

Of course, this treats the @iterator name as a free variable that can be 
falsy-tested. But it's way, way to much to expect everyone to write and 
avoid typo plus copy/paste propagation of same!

> BTW, other than as a place to hang this function, I still don't see why we need a named Symbol constructor.
>
> symbol @foo;
>
> and
>
> symbol @foo = new Symbol.

Aside: we did not agree on a contextual 'symbol' keyword, and public is 
still in the running.

We did talk about a Symbol constructor at the meeting two weeks ago, in 
order to support diagnost/debugging string association. This was in the 
private name objects proposal going way back.

> 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.

I'd agree if there wasn't "new" functionality, but there is and we've 
discussed it. It's in the wiki.

/be


More information about the es-discuss mailing list