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>A wrapped function exotic object is an exotic object that wraps a callable object. A wrapped function exotic object is callable (it has a [[Call]] internal method). Calling a wrapped function exotic object generally results in a call of its wrapped function.</p>
43
+
44
+
<p>An object is a <dfnid="wrapped-function-exotic-object">wrapped function exotic object</dfn> if its [[Call]] internal method use the following implementations, and its other essential internal methods use the definitions found in <emu-xrefhref="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>. These methods are installed in WrappedFunctionCreate.</p>
45
+
46
+
<p>Wrapped function exotic objects do not have the internal slots of ECMAScript function objects listed in <emu-xrefhref="#table-internal-slots-of-ecmascript-function-objects"></emu-xref>. Instead they have the internal slots listed in <emu-xrefhref="#table-internal-slots-of-wrapped-function-exotic-objects"></emu-xref>, in addition to [[Prototype]] and [[Extensible]].</p>
47
+
<emu-tableid="table-internal-slots-of-wrapped-function-exotic-objects"caption="Internal Slots of Wrapped Function Exotic Objects">
48
+
<table>
49
+
<tbody>
50
+
<tr>
51
+
<th>
52
+
Internal Slot
53
+
</th>
54
+
<th>
55
+
Type
56
+
</th>
57
+
<th>
58
+
Description
59
+
</th>
60
+
</tr>
61
+
<tr>
62
+
<td>
63
+
[[WrappedTargetFunction]]
64
+
</td>
65
+
<td>
66
+
Callable Object
67
+
</td>
68
+
<td>
69
+
The wrapped function object.
70
+
</td>
71
+
</tr>
72
+
<tr>
73
+
<td>
74
+
[[Realm]]
75
+
</td>
76
+
<td>
77
+
Realm Record
78
+
</td>
79
+
<td>
80
+
The realm in which the wrapped function object was created.
<p>The [[Call]] internal method of a wrapped function exotic object _F_ takes arguments _thisArgument_ (an ECMAScript language value) and _argumentsList_ (a List of ECMAScript language values). It performs the following steps when called:</p>
90
+
<emu-alg>
91
+
1. Let _target_ be _F_.[[WrappedTargetFunction]].
92
+
1.Assert: IsCallable(_target_) is *true*.
93
+
1. Let _targetRealm_ be ? GetFunctionRealm(_target_).
94
+
1. Let _callerRealm_ be ? GetFunctionRealm(_F_).
95
+
1. For each element _key_ of _argumentsList_, do
96
+
1. Let o be _argumentsList_[_key_].
97
+
1. Set _argumentsList_[_key_] to ? GetWrappedValue(_targetRealm_, _o_).
98
+
1. Let _wrappedThisArgument_ to ? GetWrappedValue(_targetRealm_, _thisArgument_).
99
+
1. Let _result_ be the Completion Record of Call(_target_, _wrappedThisArgument_, _argumentsList_).
100
+
1. If _result_.[[Type]] is ~normal~ or _result_.[[Type]] is ~return~, then
101
+
1. Set _value_ to NormalCompletion(_result_.[[Value]]).
1. Throw a newly created TypeError object associate to the _callerRealm_.
105
+
</emu-alg>
106
+
<emu-notetype=editor>
107
+
In the case of an abrupt ~throw~ completion, the type of error to be created should match the type of the abrupt throw completion record. This could be revisited when merging into the main specification. Additionally, in the case of a ~break~ or ~continue~ completion, since those are not supported, a TypeError is expected.
<p>The abstract operation WrappedFunctionCreate takes arguments _callerRealm_ and _targetFunction_. It is used to specify the creation of new wrapped function exotic objects. It performs the following steps when called:</p>
114
+
<emu-alg>
115
+
1.Assert:_callerRealm_ is a Realm Record.
116
+
1.Assert: IsCallable(_targetFunction_) is *true*.
117
+
1. Let _internalSlotsList_ be the internal slots listed in <emu-xrefhref="#table-internal-slots-of-wrapped-function-exotic-objects"></emu-xref>, plus [[Prototype]] and [[Extensible]].
118
+
1. Let _obj_ be ! MakeBasicObject(_internalSlotsList_).
119
+
1. Set _obj_.[[Prototype]] to %Function.prototype% from _callerRealm_.
120
+
1. Set _obj_.[[Call]] as described in <emu-xrefhref="#sec-wrapped-function-exotic-objects-call-thisargument-argumentslist"></emu-xref>.
121
+
1. Set _obj_.[[Realm]] to _callerRealm_.
122
+
1. Set _obj_.[[WrappedTargetFunction]] to _targetFunction_.
In the case of an abrupt ~throw~ completion, the type of error to be created should match the type of the abrupt throw completion record. This could be revisited when merging into the main specification. Additionally, in the case of a ~break~ or ~continue~ completion, since those are not supported, a TypeError is expected. There should be no ~return~ completion because this is a top level script evaluation, in which case a return |Statement| must result in a parsing error.
1. Suspend _evalContext_ and remove it from the execution context stack.
191
+
1. Resume the context that is now on the top of the execution context stack as the running execution context.
192
+
1. Return _promiseCapability_.[[Promise]].
193
+
</emu-alg>
194
+
195
+
<emu-notetype=editor>
196
+
The Realm's Execution Context is passed as a parameter _evalContext_. An alternative phrasing would be to create an extra execution context around the call to HostImportModuleBindingDynamically in order to execute within the appropriate Realm--the host can reference the current Realm to figure out how the import should work, similar to PerformRealmEval, which could be revisited when merging into the main specification.
<p>Synchronously execute a top-level script. The _sourceText_ is interpreted as a Script and evaluated with this bound to the realm's global object.</p>
273
+
274
+
<emu-alg>
275
+
1. Let _O_ be *this* value.
276
+
1. Perform ? ValidateRealmObject(_O_).
277
+
1. If Type(_sourceText_) is not String, throw a *TypeError* exception.
Extensible web: This is equivalent to dynamic import without having to evaluate a script source, which might not be available (e.g.: when CSP is blocking source evaluation).
114
304
</emu-note>
115
-
116
-
<emu-notetype=editor>
117
-
An extra execution context is created around the call to HostImportModuleDynamically in order to execute within the appropriate Realm--the host can reference the current Realm to figure out how the import should work. An alternative phrasing would be to pass the Realm as a parameter to HostImportModuleDynamically, which could be revisited when merging into the main specification.
<p>Realm.prototype.globalThis is an accessor property whose set accessor function is *undefined*. Its get accessor function performs the following steps:</p>
<p>The host-defined abstract operation HostImportModuleBindingDynamically takes arguments _callerRealm_ (a Realm Record), _evalRealm_ (a Realm Record), _specifier_ (a |ModuleSpecifier| String), _exportName_ (a |IdentifierName| String) and _promiseCapability_ (a PromiseCapability Record). It performs any necessary setup work in order to make available the module corresponding to _specifier_ occurring within the context of the script or module represented by _referencingScriptOrModule_. _referencingScriptOrModule_ is *null*. It then performs FinishDynamicImport to finish the dynamic import process.</p>
369
+
<p>The implementation of HostImportModuleBindingDynamically must conform with the implementation of HostImportModuleDynamically first and foremost, second, it should conform with the following:</p>
370
+
<li>
371
+
The host environment must conform to one of the two following sets of requirements:
372
+
<dl>
373
+
<dt>Success path</dt>
374
+
375
+
<dd>
376
+
<ul>
377
+
<li>The completion value must be the wrapped value exported value for the _exportName_ associated to the Module Namespace Object for the _callerRealm_.</li>
378
+
</ul>
379
+
</dd>
380
+
381
+
<dt>Failure path</dt>
382
+
383
+
<dd>
384
+
<ul>
385
+
<li>At some future time, the Module Namespace Object does not contain the _exportName_ as part of the ExportNames, with the abrupt completion representing the cause of failure for the _callerRealm_.</li>
0 commit comments