-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Editorial: InitializeHostDefinedRealm-related refactorings #3139
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though I think @bakkot may prefer to omit the second commit. In the past, he has been explicitly in support of these single-step definitions.
Have I? I don't have any recollection of that. |
I support being able to use the form; that doesn't mean I'm in support of every particular instance. I'm neutral in this case. |
That's the thing I was trying to say. |
64fc3ca
to
407c910
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for these changes. I wonder if everything from If the host requires
to Create any host-defined global object properties
should be moved into a single host hook with the default implementation using these steps verbatim and the HTML spec doing its own thing - I'm happy to look into changing that in light of the discussion in #3274.
I have thoughts, but maybe discussion of the proposed host hook would be better in #3274? |
Yes, I don't mean to block this PR - IMO these changes are good as is while preserving the status quo of how the global object customizations are spec'd. |
It's worth noting that https://tc39.es/proposal-shadowrealm/#sec-shadowrealm will need an update. |
4b9eb20
to
6a5342c
Compare
…ostDefinedRealm (tc39#3139( ... and put the result in the "Realms" section.
In the status quo, the value returned by SetDefaultGlobalBindings is always just the [[GlobalObject]] of the Realm Record passed in. At the only invocation of SetDefaultGlobalBindings (in InitializeHostDefinedRealm), this is `_realm_.[[GlobalObject]]`, which is just `_global_`. So use `_global_` instead of `_globalObj_` (the alias for the value returned by SetDefaultGlobalBindings), and tweak SetDefaultGlobalBindings to return ~unused~.
6a5342c
to
052defa
Compare
This is now done as part of tc39/proposal-shadowrealm#392 |
The current prose no longer works after tc39/ecma262#3139.
Folks, as part of the work at tc39/proposal-shadowrealm#409, we found some weirdness introduced by these changes, specifically, the fact that calling |
That was already the case before. Here is the full rendered diff of this PR, these lines have not changed: |
FWIW, there is more discussion around whether that behavior is desirable or not in #3274 and that PR intends to change it. |
This PR didn't change any of the net semantics of invoking |
More to the point, the AOs that shadow realms was using before got removed in this PR |
…409) The current prose no longer works after tc39/ecma262#3139.
In 9.6 InitializeHostDefinedRealm, there are two
If
-steps that allow the host to customize the global object and global*this*
binding. If the host just wants the default (of either), that's handled by passing*undefined*
to (the relevant parameter of)SetRealmGlobalObject
, which takes care of setting the realm's[[GlobalObject]]
and[[GlobalEnv]]
appropriately.This division of labor always struck me as a bit odd. E.g., why set
_global_
to*undefined*
and then have prose to explain the significance of doing so? Why not just set_global_
appropriately right there? That was the impetus for this PR. (My guess was thatSetRealmGlobalObject
was used by the HTML spec, but it isn't, and as far as I can tell it never was. Perhaps that was briefly someone's plan.)This PR is split into 6 commits for ease of review. If approved, I'll do some squashing.
I start by moving
InitializeHostDefinedRealm
to a better location.It's odd for
InitializeHostDefinedRealm
(clearly a realm-centric operation) to be out on its own in 9.6, when there's a "Realms" section at 9.3.(When Realms were introduced in ES6, the relative location of InitializeHostDefinedRealm was somewhat different and made more sense, but things have changed since then.)
Line-break the two "If the host requires" steps for readability.
Inline
SetRealmGlobalObject
intoInitializeHostDefinedRealm
.(Originally, I only hoisted out the
SetRealmGlobalObject
steps that assigned 'meanings' to the*undefined*
parameters, but that left so little inSetRealmGlobalObject
that I didn't see any reason for it to continue to exist.)Reorganize/simplify the result of the previous commit.
Tweak the return of
SetDefaultGlobalBindings
.In
SetDefaultGlobalBindings
,_global_
is an alias for_realmRec_.[[GlobalObject]]
. InInitializeHostDefinedRealm
, this is_realm_.[[GlobalObject]]
, which is just_global_
. ButSetDefaultGlobalBindings
returns that object, whichInitializeHostDefinedRealm
then assigns to_globalObj_
, meaning that we now have two aliases for the same object, which is unnecessarily confusing.So this commit tweaks
SetDefaultGlobalBindings
to return~unused~
, and tweaksInitializeHostDefinedRealm
to refer to_global_
rather than introducing_globalObj_
.Inline
CreateRealm
intoInitializeHostDefinedRealm
.This wasn't part of my original plan, but I like it because it surfaces both the early and later settings of
_realm_.[[GlobalObject]]
and_realm_.[[GlobalEnv]]
. This makes it really obvious that the early settings are transient. (See Editorial: More info in 'PromiseCapability Record' table #2380 (comment))Checking the downstream specs, nobody references
SetRealmGlobalObject
,CreateRealm
, orSetDefaultGlobalBindings
.