- From: Daniel Ehrenberg <notifications@github.com>
- Date: Mon, 04 Mar 2019 01:05:03 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/pull/675/review/210031140@github.com>
littledan commented on this pull request. > + module <mark>"std:example"</mark> { + /* module_members... */ + }; + + partial module <mark>"std:example"</mark> { + /* module_members... */ + }; +</pre> + +Note: As with partial interface definitions, partial module definitions are +intended for use as a specification editorial aide, allowing the definition +of a module to be separated over more than one section of the document, and +sometimes multiple documents. + +The order that members appear in has significance for property enumeration in +the <a href="#es-modules">ECMAScript binding</a>. I'd be a little uncomfortable with the order being "alphabetization", as we previously discussed--this would be a little unidiomatic to require of JavaScript implementations of built-in modules. I thought we'd handle this non-determinism in a separate, orthogonal PR. Another option would be to delay partial modules until later. I don't have any use cases in mind for partial modules, but I'm not sure if implementations are eager to split up IDL for a single module into multiple files. (When I commented that I'm not sure if this handles partials correctly, I'm especially worried about partial implementations as module members, and if it's OK to just pretend that the partials don't exist in the later algorithms as they're already merged in.) -- 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#discussion_r261969731
Received on Monday, 4 March 2019 09:05:27 UTC