Symbols, Protocols, Frames, and Versioning

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Oct 4 12:12:57 PDT 2012


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

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

The strawman for at-name declarations with initializers do not allow binding of an at-name to anything other than a symbol value.  The above would throw if Symbol.lookup returned undefined  or anything else that was not a symbol value.


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

Right we didn't agree on public vs symbol vs unique.  I just used "symbol" to avoid the appearance that there was consensus around "public".


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

Yes, I originally proposed the idea of  associating a debug name with a symbol value. However, I don't remember it specifically being mentioned at the meeting as a justification for the constructor.

I'm not sure if that debug usage, by itself, would be enough to convince me, that we need the Symbol constructor.  It is more compelling if  there is more functionality such as lookup/intern that needs to have a home.

Allen


More information about the es-discuss mailing list