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

Allow exotic global #38

Open
Jamesernator opened this issue Feb 10, 2021 · 1 comment
Open

Allow exotic global #38

Jamesernator opened this issue Feb 10, 2021 · 1 comment

Comments

@Jamesernator
Copy link

Jamesernator commented Feb 10, 2021

In the current proposal, the globalThis object is created automatically and can only be extended by attaching properties to it. However actual global objects may be exotic, the most obvious example of this is the HTML WindowProxy object. In order to be able to simulate behaviour of these objects, we need to be able to add exotic behaviour to the globalThis object.

Now in the spec it allows globalThis to be any object, however it's unclear to whether or not implementations would actually be prepared for arbitrary objects to be the globalThis. An alternative that I propose here is to add a hook for providing proxy traps that are used for the creation of the global object.

For example it might look something like:

const compartment = new Compartment({
  globalThisProxyHooks: {
    get(prop) {
      return prop;
    },
  },
});

console.log(compartment.globalThis.someProp); // "someProp"
@erights
Copy link
Collaborator

erights commented Feb 10, 2021

unclear to whether or not implementations would actually be prepared for arbitrary objects to be the globalThis.

The last time we asked, the answer was that implementations would not be happy about that. A lot has happened since then so if there's a reason we would ask again. But I doubt this answer would change.

An alternative that I propose here is to add a hook for providing proxy traps that are used for the creation of the global object.

This idea of providing a proxy handler (or, presumably a proxy handler and target) so that the compartment constructor could create a fresh proxy, has been raised before. In fact I think it may have been part of the first realms proposal by, I think, @dherman , before the old realms split into the modern realms and the modern compartments. This would actually fit bizarrely well with how the SES shim shims evaluation --- with a with on a proxy using the eight magic lines of code https://www.youtube.com/watch?v=mSNxsn0pK74&list=PLzDw4TTug5O3vIAd4IR1Gp5t_46co_dv9&t=799s at 37:39

I expect this would be controversial enough that the initial compartment proposal should not propose it, though it should mention it as an intriguing future possibility.

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

No branches or pull requests

2 participants