Create TypeErrors and Promises in the correct realm
#242
Conversation
ExE-Boss
changed the title
Errors, Arrays and Promises in the correct realm
ExE-Boss
changed the title
Errors, Arrays and Promises in the correct realmTypeErrors and Promises in the correct realm
domenic
left a comment
domenic
left a comment
There was a problem hiding this comment.
Although this isn't technically correct (as it uses the relevant realm, not the current realm), this is an exciting step in the right direction. Although we might, at some point, have to undo this work if we do something like we talked about in jsdom/jsdom#2727, it's still worthwhile in the meantime, I think.
| value, | ||
| { | ||
| context = \\"The provided value\\", | ||
| ctorRegistry = { \\"%TypeError%\\": TypeError, \\"%Number%\\": Number, \\"%Promise%\\": Promise, \\"%String%\\": String } |
There was a problem hiding this comment.
Hmm. I think it'd be a bit more uniform for consumers if the convert algorithm took a mandatory first-parameter global, similar to create() and friends.
| } | ||
|
|
||
| // The result is used as the `globals` property of the `options` parameter for `webidl-conversions`: | ||
| function conversionGlobalsFromCtorRegistry(ctorRegistry) { |
There was a problem hiding this comment.
Let's stop storing the intrinsics under "%TypeError" and instead store them under "TypeError". Then we can get rid of this function entirely and just pass the ctorRegistry.
Closes #242 by superseding it.
Closes #242 by superseding it.
Closes #242 by superseding it. This approach moves the ctorRegistry back to being mostly for the registration of WebIDL2JS-generated constructors. We use the globalObject variable to pass to webidl-conversions and to find our Promise and TypeError constructors.
2 participants
This makes it so that
TypeErrors andPromises are created with the correct prototype chain.Depends on: