| 08:03 | <devsnek> | is the functionality requested here something that browsers are able to do (and therefore something that js engines implement)? https://github.com/nodejs/node/issues/31807 |
| 17:44 | <Domenic> | devsnek: yes |
| 17:45 | <Domenic> | https://html.spec.whatwg.org/#creating-browsing-contexts:concept-windowproxy-window |
| 17:46 | <Domenic> | Well, I'm not sure |
| 17:46 | <Domenic> | Browsers don't change a realm's global after the fact |
| 17:46 | <Domenic> | They keep the global and globalThis the same |
| 17:46 | <Domenic> | And change an internal property of the globalThis |
| 17:46 | <Domenic> | But they don't interface with the ES spec more than at setup time |
| 17:47 | <Domenic> | Maybe they do interface with V8 more than at setup time, to make things fast, I dunno. |
| 17:59 | <devsnek> | Domenic: so if they're just changing some internal slot |
| 17:59 | <devsnek> | that probably isn't a thing js engines themselves implement |
| 17:59 | <devsnek> | its just changing some variable somewhere |
| 17:59 | <devsnek> | a private symbol or a c++ field or smth |
| 17:59 | <Domenic> | I'm not sure; I kind of doubt JS/web engines map 1:1 with specs for this sort of low-level stuff |
| 18:00 | <Domenic> | But yeah in theory if Node already provided a way to create a realm with separate globalThis and global then this could be implemented 1:1 with the spec with nothing further |
| 18:01 | <Domenic> | I guess what you really need though is some kind of "instruction for creating global and globalThis" since the objects need to be created in the new realm |
| 18:02 | <Domenic> | well, at least global; I guess globalThis the realm doesn't matter since it just delegates all obervable properties to another object created inside the new realm |
| 18:07 | <devsnek> | ok i think i figured it out |
| 18:07 | <devsnek> | with v8 when you pass an object to become the global, the internal map gets wiped, it just retains identity |