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

[js-api] @@toStringTag values #1023

Closed
binji opened this issue May 20, 2019 · 6 comments
Closed

[js-api] @@toStringTag values #1023

binji opened this issue May 20, 2019 · 6 comments

Comments

@binji
Copy link
Member

binji commented May 20, 2019

Associated values for the @@toStringTag well-known symbol were originally added to the design repo here.

It seems we never added these to the js-api spec, though there is a reference to @@toStringTag here. The last reference seems to be the initial check-in in #591.

Was this an accidental omission? @littledan, do you know?

@littledan
Copy link
Collaborator

These are defined by the WebIDL specification to be values like "WebAssembly.Memory". Was that the intention?

@binji
Copy link
Member Author

binji commented May 20, 2019

Yes, that's the intention. It wasn't clear to me (and in https://bugs.chromium.org/p/v8/issues/detail?id=9265), but if this is otherwise well-known then there probably doesn't need to be any fix here.

@binji binji closed this as completed May 20, 2019
@binji
Copy link
Member Author

binji commented May 20, 2019

Hm, actually -- where is this defined? I see https://heycam.github.io/webidl/#ecmascript-binding, but it seems to require a "class string" definition.

@binji binji reopened this May 20, 2019
@littledan
Copy link
Collaborator

The class string of a platform object that implements one or more interfaces must be the qualified name of the primary interface of the platform object

@littledan
Copy link
Collaborator

There is, unfortunately, an open debate about how @@toStringTag should work. I like @domenic's PR at whatwg/webidl#357 , and it matches the old specification. I would personally suggest that folks stick with those semantics while we work things out on the WebIDL side.

@binji
Copy link
Member Author

binji commented May 20, 2019

Ah, I see. Thanks! OK, I think we should close this then.

@binji binji closed this as completed May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants