Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why are the toStringTag values "Object"? #176

Closed
littledan opened this issue Sep 14, 2017 · 2 comments · Fixed by #430
Closed

Why are the toStringTag values "Object"? #176

littledan opened this issue Sep 14, 2017 · 2 comments · Fixed by #430
Labels
c: meta Component: intl-wide issues s: help wanted Status: help wanted; needs proposal champion

Comments

@littledan
Copy link
Member

It would seem more intuitive that, for example, Intl.Collator[Symbol.toStringTag] would be "Intl.Collator". Is this done for compatibility reasons, where we're aware of a site that depends on toString() on Intl objects returning "[Object object]"? For new APIs, should we use "Object" or the name of the class, if we're not constrained by compatibility?

@allenwb
Copy link
Member

allenwb commented Sep 14, 2017

When the first edition of ECMA-402 was done it was targeting ES5.1. Prior to ES6 we didn't have an extensibility mechanism (eg, Symbol.toStringTag) for userland extensions to Object.prototype.toString. So, the various Intl objects just inherited the default "[Object object]" behavior.

While it would technically be a breaking change, my guess is that we could get away with giving these objects a more meaningful toStringTag value as "[Object object]" is not a very useful discriminator.

@littledan
Copy link
Member Author

Would anyone be interested in writing a PR to change the @@toStringTag values appropriately?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: meta Component: intl-wide issues s: help wanted Status: help wanted; needs proposal champion
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants