Discuss
  • Property names for public symbols

Property names for public symbols

# Axel Rauschmayer (10 years ago)

I know that this is a small nit and that it’s probably too late, but: Shouldn’t public symbols (Symbol.iterator etc.) have all-uppercase property names? It would indicate that they are constants and it would visually set them apart from other stuff that is in Symbol (Symbol.for() etc.).

# Mark Volkmann (10 years ago)

Agreed, like at the constants on the Math object.

# Gary Guo (10 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20150207/e25e3f5c/attachment

# Brendan Eich (10 years ago)

Some tasteful inconsistency (the hobgoblin of big minds) is required here. We want the well known symbols' names as static properties of Symbol to be same-named.

# Axel Rauschmayer (10 years ago)

Can you explain what you mean by “same-named”? You want Symbol.for() to have the same casing as Symbol.iterator?

# Brendan Eich (10 years ago)

No, I mean we would normally use iterator (and had __iterator__ in SpiderMonkey, then '@@iterator' I believe), not ITERATOR. Python's dunder-bracketing doesn't cut it, symbols win. But UPPERCASE loses.

# Axel Rauschmayer (10 years ago)

Got it: public symbols stand for property names and those are typically camel-case, starting with a lowercase letter.

# Mark Volkmann (10 years ago)

I'm curious why one of the public symbols has a name that ends with "Tag" ("toStringTag"), but the others don't (such as "toPrimitive"). Maybe "toStringTag" should be changed to "toString".

# Axel Rauschmayer (10 years ago)

This symbol is about the string tag.

# Brendan Eich (10 years ago)

Mark Volkmann wrote:

I'm curious why one of the public symbols has a name that ends with "Tag" ("toStringTag"), but the others don't (such as "toPrimitive"). Maybe "toStringTag" should be changed to "toString".

That would be the wrong name -- the Tag is specific, particular to the purpose of this symbol. It's not an under-used generic suffix for all well-known symbol names. See people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring.

# Gary Guo (10 years ago)

How about "classTag" instead of "toStringTag", which makes it sound like a noun.

# Jordan Harband (10 years ago)

"[[Class]]" was the pre-ES6 term to refer to this value, but with the ES6 "class" keyword that would be confusing, and I don't think it would be a good idea to conflate the meaning of the term even further. "toString" is a common single idiom in JS since it's the function that String() invokes, so "toStringTag" works for me.

This particular value is one that, imo, in practice should be rarely used (once per "class" perhaps, in its definition), so I'm not hugely concerned about the naming (my concerns were about the behavior). My guess would be that in order to effect a change at this very late date, one would have to propose a name that was so compelling as to make it an obvious choice.

# Gary Guo (10 years ago)

Actually I disagree with you. Class will not be confusing, since as you said, people probably will use toStringTag once per class. So classTag just becomes a better name. String, Boolean, etc, are just names of classes.

# Jordan Harband (10 years ago)

Based on my understanding of the spec, I'd say that String, Boolean, etc are not "classes" at all, since they don't have a [[HomeObject]] - they're just constructor functions.