Skip to content
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

Global inherits from %ObjectPrototype% #14

Open
bmeck opened this issue Mar 29, 2016 · 3 comments
Open

Global inherits from %ObjectPrototype% #14

bmeck opened this issue Mar 29, 2016 · 3 comments
Labels

Comments

@bmeck
Copy link
Member

bmeck commented Mar 29, 2016

This mandate is not in ES spec. It would be a mandate solely for frozen-realms and may cause oddities if the parent realm does not inherit from %ObjectPrototype%. Also keeps strange behaviors around like new constructor().

previous discussion at: https://esdiscuss.org/topic/proposal-revisions-draft-proposed-standard-ses-becomes-draft-proposed-frozen-realm-api#content-1

@erights
Copy link
Collaborator

erights commented Apr 15, 2016

The frozen realm omits all host objects and so is not considered a host-specific kind of realm. We should prefer more deterministic specs to less deterministic specs. Thus, we should specify what the frozen global inherits from, i.e., what the value of the frozen realm's global's [[Prototype]] is. If we do not specify that it is the frozen realm's %ObjectPrototype%, what value should we specify? What are the other plausible candidates?

The only plausible one that comes to mind is null. Would that be better? It would avoid the new constructor() weirdness. However, unless we add toString as a standard global property/variable, the global would not be stringable. Is there anything else normally on %ObjectPrototype% that we should add directly to the frozen global if we do have it inherit from null?

@caridy
Copy link
Collaborator

caridy commented May 11, 2016

FYI, in the current spec text for this repo, neither spawned realms, and immutableRoot realms have a way to control the realm's [[GlobalObject]] internal slot, it will always be a newly created object of the newly created realm's %ObjectPrototype% intrinsic.

Although, when creating new realms via new Realm() you will have the ability to pass a target and a handler to create a proxy object that will be used as a [[GlobalObject]] of the new realm. More details here: https://rawgit.com/caridy/proposal-realms/master/index.html#sec-realm

@erights
Copy link
Collaborator

erights commented May 11, 2016

What needs to be said to ensure that the platform-created global is initialized only with things from the ES spec, and not with, e.g., any host-provided properties.

I think we need to state explicitly that https://tc39.github.io/ecma262/#sec-setdefaultglobalbindings must not add any properties other than "each property of the Global Object specified in clause 18,". Proposing that this be changed unconditionally in the language at 8.2.4 is best. If for some reason we can't get that, then we need to make sure that frozen realms engage a variant that does have this guarantee. Likewise with the initial state of all the objects that are magically created by the realm initialization mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants