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

Built-in module conventions #755

Closed
Ms2ger opened this issue Jul 2, 2019 · 5 comments
Closed

Built-in module conventions #755

Ms2ger opened this issue Jul 2, 2019 · 5 comments

Comments

@Ms2ger
Copy link
Member

Ms2ger commented Jul 2, 2019

There's been a number of discussions around conventions for built-in modules, in particular:

Let's figure out what we want, and involve TC39 in the discussion as well, potentially at the 23-25 July 2019 F2F meeting.

CC @domenic @annevk @bzbarsky

@domenic
Copy link
Member

domenic commented Jul 15, 2019

For the record: in KV Storage, I've done the following:

  • Enumerability of methods/accessors: chosen enumerable, like the web platform built-in globals, unlike JS-spec built-in globals. Whichever is chosen here, changing would be a very slight breaking change, that in practice is unlikely to break consumers, because enumerability of built-ins very rarely impacts JS code.
  • Same-realm brand checks: adopted, via Introduce a SameRealmBrandCheck extended attribute #718. If we decided not to do this, it would be a backward-compatible loosening to change KV Storage.
  • Freezing: not adopted, largely because there is no concrete proposal. If we decided to do this, it would be a backward-incompatible change with medium risk. Code that tries to monkeypatch KV Storage objects would start throwing errors.

Looking at the above, it may be more conservative to spec/implement KV Storage with freezing initially, hmm. But I am really unclear whether that's being seriously pursued. I will try to gather more information at TC39.

@ljharb
Copy link
Contributor

ljharb commented Jul 24, 2019

Are web platform built-in globals made enumerable for intentional reasons, or to be consistent with legacy choices? If the former, what are the reasons?

@domenic
Copy link
Member

domenic commented Jul 25, 2019

My impression is legacy choices, but the decision predates me. @bzbarsky or @heycam are our best bets here, perhaps?

@bzbarsky
Copy link
Collaborator

I believe they were enumerable in all browsers when the Web IDL spec was written, and the spec just reflected that.

@ljharb
Copy link
Contributor

ljharb commented Jul 25, 2019

In that case (re enumerability) it seems like a clean break opportunity for the web to start mirroring the language, and go non-enumerable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants