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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
