You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>See <a href="https://github.com/styfle/proposal-import-bytes/blob/main/README.md">the explainer</a> for information.</p>
14
14
<emu-note type="editor">
15
-
<p>This proposal is buit on top of the <a href="https://github.com/tc39/proposal-import-attributes">Import Attributes</a> proposal.</p>
15
+
<p>This proposal is buit on top of the <a href="https://github.com/tc39/proposal-json-modules">JSON Modules</a> and <a href="https://github.com/tc39/proposal-immutable-arraybuffer">Immutable Array Buffer</a> proposals.</p>
16
16
</emu-note>
17
17
</emu-intro>
18
18
@@ -56,9 +56,13 @@ contributors: Steven
56
56
</ul>
57
57
<p>then it must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) with the same _result_ each time.</p>
58
58
</li>
59
-
<li>
60
-
<p><ins>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"* and _entry_.[[Value]] is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</ins></p>
61
-
</li>
59
+
<li><p><del>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"* and _entry_.[[Value]] is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</del></p></li>
60
+
<li><p><ins>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"*, then</ins></p></li>
61
+
<ol>
62
+
<li><p><ins>Let _type_ be _entry_.[[Value]].</ins></p></li>
63
+
<li><p><ins>If _type_ is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</ins></p></li>
64
+
<li><p><ins>If _type_ is *"buffer"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of CreateBufferModule or a throw completion.</ins></p></li>
65
+
</ol>
62
66
<li>
63
67
The operation must treat _payload_ as an opaque value to be passed through to FinishLoadingImportedModule.
64
68
</li>
@@ -67,11 +71,11 @@ contributors: Steven
67
71
<p>The actual process performed is host-defined, but typically consists of performing whatever I/O operations are necessary to load the appropriate Module Record. Multiple different (_referrer_, _moduleRequest_.[[Specifer]], _moduleRequest_.[[Attributes]]) triples may map to the same Module Record instance. The actual mapping semantics is host-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as expansion of relative and abbreviated path specifiers.</p>
68
72
69
73
<emu-note>
70
-
<p><ins>The above text implies that hosts *must* support JSON modules imported with `type: "json"` (if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.</ins></p>
74
+
<p>The above text implies that hosts *must* support JSON modules <ins>and buffer modules</ins> imported with `type: "json"` <ins>and `type: "buffer"` respectively </ins>(if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.</p>
71
75
</emu-note>
72
76
73
77
<emu-note>
74
-
<p><ins>All of the import statements in the module graph that address the same JSON module may evaluate to the same mutable object.</ins></p>
78
+
<p>All of the import statements in the module graph that address the same JSON <ins>or buffer </ins>module may evaluate to the same mutable object.</p>
75
79
</emu-note>
76
80
</emu-clause>
77
81
@@ -80,7 +84,7 @@ contributors: Steven
80
84
81
85
<p>A <dfn variants="Synthetic Module Records">Synthetic Module Record</dfn> is used to represent information about a module that is defined by specifications. Its exports are derived from a pair of lists, of string keys and of ECMAScript values. The set of exported names is static, and determined at creation time (as an argument to CreateSyntheticModule), while the set of exported values can be changed over time using SetSyntheticModuleExport. It has no imports or dependencies.</p>
82
86
83
-
<emu-note>A Synthetic Module Record could be used for defining a variety of module types: for example, built-in modules, or JSON modules, or CSS modules.</emu-note>
87
+
<emu-note>A Synthetic Module Record could be used for defining a variety of module types: for example, built-in modules, or JSON modules, <ins>or buffer modules, </ins>or CSS modules.</emu-note>
84
88
85
89
<p>In addition to the fields defined in <emu-xref href="#table-module-record-fields"></emu-xref> Synthetic Module Records have the additional fields listed in <emu-xref href="#table-synthetic-module-record-fields"></emu-xref>. Each of these fields is initially set in CreateSyntheticModule.</p>
<emu-note type="editor">It seems we could set up the environment either here or in Link(). I've chosen to do so in Link() for symmetry with Cyclic Module Records (and thus Source Text Module Records), but I don't think there's any actual requirement in that regard.</emu-note>
<p>The following are the concrete methods for Synthetic Module Record that implement the corresponding Module Record abstract methods.</p>
154
-
155
-
<emu-note type="editor">I find having this wrapping sub-clause cleaner and suggest we do the same for Source Text Module Records in the main spec.</emu-note>
<dd>It creates a Synthetic Module Record whose default export is _defaultExport_.</dd>
261
-
</dl>
262
-
<emu-alg>
263
-
1. Let _realm_ be the current Realm Record.
264
-
1. Let _setDefaultExport_ be a new Abstract Closure with parameters (_module_) that captures _defaultExport_ and performs the following steps when called:
0 commit comments