W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

Associating new objects with globals: how to best do it?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 25 Feb 2014 12:45:12 -0500
Message-ID: <530CD6A8.9000101@mit.edu>
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 

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 

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:


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 

Received on Tuesday, 25 February 2014 17:45:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC