-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider storing the associated "parent" Realm in an internal slot #285
Comments
sounds good to me! I decided to used |
@littledan can you update on this? Thanks! |
My current focus is on completing an initial description of the HTML embedding, which works fine without this editorial change, as I explained. With the editorial variant described in #whatwg/html#6855, the whole "synthetic realm settings object" concept basically exists just to point to the parent realm. So, this change might be a nice cleanup, but it is not urgent. |
I believe this is now resolved. |
Could you explain how it's resolved? As far as I can tell the HTML PR still uses [[HostDefined]] for this. |
In the HTML integration patch for Realms, HTML keeps track of the parent Realm of each synthetic Realm created in this API as part of a record stored in its [[HostDefined]] field. The parent Realm is used to key off of for various behaviors at the HTML level.
While this mechanism can be defined accurately at the HTML level, it is likely meaningful in other environments as well (cc @jasnell who has been thinking about this for Node.js). So, we should consider defining the parent Realm in a field of the record for synthetic Realms, to facilitate this.
Thanks to @annevk for pointing out this issue.
This is a minor editorial/layering issue that does not block Stage 3 and can be iterated on after it.
The text was updated successfully, but these errors were encountered: