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