- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 25 Feb 2014 12:45:12 -0500
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>
- CC: Bobby Holley <bholley@mozilla.com>
Bobby and I were just discussing how newly created objects are (or rather should be) associated with globals. Here's the situation as I currently understand it: 1) Every newly object is, generally speaking, associated with a global by default via its proto chain. I realize script can munge those proto chains (e.g. by making Node.prototype.__proto__ in one window be EventTarget.prototype from another window); I'm talking about the default behavior. 2) Every function is associated with some global; in ES6 this is formalized by the [[Realm]] internal slot of functions, from which a global is reachable. 3) Currently WebIDL requires all objects to explicitly say what global they're associated with. This requirement is observed by pretty much no one. 4) In ES6, there is some informal concept of an "ambient global". For example, when a built-in function is called that ambient global is the global of the [[Realm]] of that built-in function. Operations that create new objects associate them with the default prototypes of that ambient global. If this is correct, it might be good to formalize this somehow... Is my understanding correct so far? We've talked about some sort of default global-association for WebIDL methods and geteters. Would it make sense to align this with the ES6 behavior by declaring that if a WebIDL method creates objects it does so in the global of the callee function unless something explicitly specifies otherwise? So in this case: window1.SomeInterface.prototype.someMethod.call(objectFromWindow2) the return value object would be created in window1, not window2, by default? Same thing for getters, of course. Obviously, some DOM specs would need to go through and explicitly specify globals for some objects (e.g. nodes), but the vast majority of specs should be able to get away with just not having to say anything. This has the benefit of not needing any extra work for static WebIDL methods and getters, which generally ignore their this value entirely at the moment... Thoughts? Did I understand the ES6 behavior we're trying to align with correctly? -Boris
Received on Tuesday, 25 February 2014 17:45:43 UTC