Re: [heycam/webidl] [WIP] Define Web IDL Modules (#675)

I was hoping that this would be OK to have two different interfaces named `Y`, one inside a module and one not. I hope modules will let us scale up spec development exactly for this kind of reason. In drafting this text, I was having trouble finding what I would have to change/clarify to make sure that a later `partial interface Y` wouldn't merge with the interface in the module.

`[Exposed]` and `[SecureContext]` are not allowed just because it'd be a bunch of extra complexity:
- On the spec side: if you have `partial module "std:foo" { partial interface Bar { void method(); } }`, you'd have to check five things to understand how the exposure-related extended attributes apply to `method`: the main module, the partial module, the main interface, the partial interface, and the operation. We could specify this, but it'd be a bit more complicated, and not simply the current algorithm of (roughly) "traverse up until you find the attribute".
- On the implementation side: if you write a built-in module in JavaScript, you'd have to provide an entirely different version to omit certain named exports, as the list of exported names is static and indicated in the JavaScript code. And if you use a JavaScript class, you'd have to mutate the result to update visibility.
- On use cases: I think modules will be a bit more granular than some of the mega-interfaces that the Web has been evolving over time. So I think that these attributes make less sense for things inside of modules.

If you think full expressiveness here is important, I could update this patch to do that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/675#issuecomment-469204592