dherman/globals-chat.txt

## globals-chat.txt
20:54	dherman	1. I imagine an object can only be a global object for one realm, right?
20:54	shu	oh my word yes
20:54	dherman	lol
20:54	dherman	don't panic
20:54	dherman	I'm just collecting invariants
20:54	dherman	(this is for the Realm API)
20:54	dherman	2. if you had a pre-existing object,
20:54	dherman	that isn't a global object
20:55	dherman	would it be problematic to allow using that object as a global object for a new realm?
20:55	shu	yes, the thing that's actually branded GlobalObjects internally can't be just any plain object
20:55	dherman	I'm kind of simultaneously asking a) is that impossible today and b) whether it's impossible to imagine that ever changing
20:56	Waldo	dherman: are you suggesting that arbitrary objects would start magically gaining the [[]] internal properties of the global object at some point?
20:56	Waldo	or at least that that's a possibility?
20:56	shu	at least a) is yes
20:57	shu	b) i imagine it to require an audit, but my hunch is it would be difficult
20:57	The_8472	why not model it after sandboxes? they take other objects as prototypes for the new global
20:57	Waldo	The_8472: global objects are presumed very special right now; the prototype relationship is not nearly so special
20:58	dherman	shu: ok cool, this is what I'm looking for
20:58	dherman	I'm not actually lobbying to change it
20:58	dherman	in fact I highly doubt it's important to change it
20:58	dherman	the way I designed the proposal,
20:58	dherman	you don't get to pass in an object to use as the global
20:58	dherman	when you create a `new Realm()` it synthesizes a new global object
20:58	shu	dherman: the main question is is it merely an interceding object with names you want to introduce at global scope, or do you want plain objects to be able to be used exactly as global objects
20:59	dherman	again, I don't *want* this
20:59	The_8472	Waldo, yeah, i was just suggesting it as an example of something realmish that works today
20:59	dherman	I'm just trying to gather what the consequences would be if we did
20:59	shu	dherman: sorry, "are you asking about"
20:59	dherman	ah ok
20:59	dherman	so
20:59	dherman	I think proooobably the latter
20:59	shu	dherman: impl may be easier for us given a compartment-global split
21:00	shu	dherman: but right now, a bunch of weirdo ES internal state is specced on the global itself, cf. [[VarNames]] and [[TemplateMap]]
21:00	dherman	oh?
21:00	shu	dherman: i believe other engines straight up implement those on the global object
21:00	dherman	I see
21:00	shu	dherman: that may be annoying to implement if one were to suddenly allow random objects to be branded as GlobalObject
21:00	dherman	so here's another weird question
21:01	sfink	3rd option would be creating a to-be-global object in one realm, and then creating a realm for it. So not just any old plain object, but one intended to be a global object in the future. (Not that I would want to implement such a thing.)
21:01	dherman	sfink: true
21:01	shu	OTOH a Realm spec may force implementation to come up with a realm-global split internally in implementation
21:01	dherman	sfink: in the end I'm not sure how much expressiveness that actually buys you
21:01	sfink	well, I'm certainly not arguing for it!
21:02	dherman	shu: absent any new information, I still think we should have global-per-realm
21:02	dherman	i.e. no split
21:02	shu	dherman: i agree, yeah. that would be the easiest thing to get through
21:02	dherman	ok so last question for now:
21:02	dherman	3. if the Realm API let you choose a custom`this` binding at global scope, i.e. it could be something other than the global object, would that pose any problems for implementations?
21:03	shu	dherman: to implement correctly, i don't think so
21:03	dherman	ok cool
21:03	dherman	I'm not sure how much I want that either
21:03	shu	dherman: to implement efficiently... i don't think so either, i imagine you don't get to mutate the reference for `this` after Realm is created?
21:04	dherman	no, we wouldn't let you mutate it
21:04	shu	dherman: yeah that'd be straightforward to implement
21:04	dherman	ok
21:04	dherman	I'm not sure if we want to introdce that variability into the ecosystem
21:04	dherman	but I think modules have an undefined `this` so maybe just allowing you to choose to have `this` be undefined?
21:04	dherman	not sure
21:05	dherman	haven't thought that one through
21:05	dherman	shu: I think that's all I got for the moment, thanks!
21:05	Waldo	sfink: "I wish our own code was up to its standard more often" lolsob
21:05	shu	dherman: cool
21:12	till	dherman, shu: we effectively have the "other object than the global" for our self-hosting stuff. All global lookups are changed to "do the lookup on this other object" when emitting bytecode for self-hosting JS
	20:54 dherman 1. I imagine an object can only be a global object for one realm, right?
	20:54 shu oh my word yes
	20:54 dherman lol
	20:54 dherman don't panic
	20:54 dherman I'm just collecting invariants
	20:54 dherman (this is for the Realm API)
	20:54 dherman 2. if you had a pre-existing object,
	20:54 dherman that isn't a global object
	20:55 dherman would it be problematic to allow using that object as a global object for a new realm?
	20:55 shu yes, the thing that's actually branded GlobalObjects internally can't be just any plain object
	20:55 dherman I'm kind of simultaneously asking a) is that impossible today and b) whether it's impossible to imagine that ever changing
	20:56 Waldo dherman: are you suggesting that arbitrary objects would start magically gaining the [[]] internal properties of the global object at some point?
	20:56 Waldo or at least that that's a possibility?
	20:56 shu at least a) is yes
	20:57 shu b) i imagine it to require an audit, but my hunch is it would be difficult
	20:57 The_8472 why not model it after sandboxes? they take other objects as prototypes for the new global
	20:57 Waldo The_8472: global objects are presumed very special right now; the prototype relationship is not nearly so special
	20:58 dherman shu: ok cool, this is what I'm looking for
	20:58 dherman I'm not actually lobbying to change it
	20:58 dherman in fact I highly doubt it's important to change it
	20:58 dherman the way I designed the proposal,
	20:58 dherman you don't get to pass in an object to use as the global
	20:58 dherman when you create a `new Realm()` it synthesizes a new global object
	20:58 shu dherman: the main question is is it merely an interceding object with names you want to introduce at global scope, or do you want plain objects to be able to be used exactly as global objects
	20:59 dherman again, I don't want this
	20:59 The_8472 Waldo, yeah, i was just suggesting it as an example of something realmish that works today
	20:59 dherman I'm just trying to gather what the consequences would be if we did
	20:59 shu dherman: sorry, "are you asking about"
	20:59 dherman ah ok
	20:59 dherman so
	20:59 dherman I think proooobably the latter
	20:59 shu dherman: impl may be easier for us given a compartment-global split
	21:00 shu dherman: but right now, a bunch of weirdo ES internal state is specced on the global itself, cf. [[VarNames]] and [[TemplateMap]]
	21:00 dherman oh?
	21:00 shu dherman: i believe other engines straight up implement those on the global object
	21:00 dherman I see
	21:00 shu dherman: that may be annoying to implement if one were to suddenly allow random objects to be branded as GlobalObject
	21:00 dherman so here's another weird question
	21:01 sfink 3rd option would be creating a to-be-global object in one realm, and then creating a realm for it. So not just any old plain object, but one intended to be a global object in the future. (Not that I would want to implement such a thing.)
	21:01 dherman sfink: true
	21:01 shu OTOH a Realm spec may force implementation to come up with a realm-global split internally in implementation
	21:01 dherman sfink: in the end I'm not sure how much expressiveness that actually buys you
	21:01 sfink well, I'm certainly not arguing for it!
	21:02 dherman shu: absent any new information, I still think we should have global-per-realm
	21:02 dherman i.e. no split
	21:02 shu dherman: i agree, yeah. that would be the easiest thing to get through
	21:02 dherman ok so last question for now:
	21:02 dherman 3. if the Realm API let you choose a custom`this` binding at global scope, i.e. it could be something other than the global object, would that pose any problems for implementations?
	21:03 shu dherman: to implement correctly, i don't think so
	21:03 dherman ok cool
	21:03 dherman I'm not sure how much I want that either
	21:03 shu dherman: to implement efficiently... i don't think so either, i imagine you don't get to mutate the reference for `this` after Realm is created?
	21:04 dherman no, we wouldn't let you mutate it
	21:04 shu dherman: yeah that'd be straightforward to implement
	21:04 dherman ok
	21:04 dherman I'm not sure if we want to introdce that variability into the ecosystem
	21:04 dherman but I think modules have an undefined `this` so maybe just allowing you to choose to have `this` be undefined?
	21:04 dherman not sure
	21:05 dherman haven't thought that one through
	21:05 dherman shu: I think that's all I got for the moment, thanks!
	21:05 Waldo sfink: "I wish our own code was up to its standard more often" lolsob
	21:05 shu dherman: cool
	21:12 till dherman, shu: we effectively have the "other object than the global" for our self-hosting stuff. All global lookups are changed to "do the lookup on this other object" when emitting bytecode for self-hosting JS