- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 25 Feb 2014 14:57:20 -0500
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, Bobby Holley <bholley@mozilla.com>
On 2/25/14 1:48 PM, Allen Wirfs-Brock wrote: > I believe by "globals" you mean what the ES6 spec. calls a Realm. Correct. > Strictly speaking, ordinary non-function objects aren't associated with a specific Realms. Strictly speaking, yes. In practice, with the exception of Object.create(null) newly created objects that are returned by APIs will be hooked up to some built-in prototype, and which exact built-in prototype is used is observable and hence needs to be specified. It sounds like we agree on all this, fwiw. > For example, each Realm has its own Object.prototype object Indeed, and Node.prototype, etc, etc. > When an Object constructor creates a new object it always sets the [[Prototyope]] of the new object to the Object.prototype object from the same Realm as the constructor. This is worth pausing on for a second. What the spec at http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value says is: If value is null, undefined or not supplied return the result of the abstract operation ObjectCreate with the intrinsic object %ObjectPrototype% as its argument. This does not explicitly mention Realms anywhere, and is what I meant in my discussion of ES having an implicit concept of "ambient Realm" or some such. > When a function is called, its Realm association becomes the "current Realm" Ah, ok. That's what I meant by "ambient": the specifications of function guts assume that there is some current Realm so they don't have to explicitly talk about which Realm they're using for things like %ObjectPrototype%. You're absolutely correct that this is not at all informal; it's pretty clearly defined. > Everything that happens within an ECMAscript program happens in the context of executing some function (or a global script that is treated as if it was a function body) While true at the moment of pure ES, this property does not hold for "ES + DOM" and may stop holding for ES itself in the future. The API pattern that breaks down this property is an API that asynchronously performs some work that creates an object and then invokes some callback (or resolves some Promise) and hands it that object. Such APIs need to use standard prototypes from some Realm when doing the async object creation. Presumably the consistent thing to do here would be to use the [[Realm]] of the API entry point that kicked off the async operation. > Approximately, subject to the above clarifications. OK, it sounds like we agree on the important bits of this. ;) > Just to be clear, when you say "callee" above you mean the WebIDL method under discussion. Yes. > If so, then what you are describing is consistent with the ES6 requirements. A function that creates a new object normally initializes the new object (eg, sets its [[Prototype]]) using the Realm of the creating function. OK, good. > yes, assuming that someMethod was originally created in the same Realm as window1. Sure. The example was an example, executed in a vanilla environment. Obviously people can muck with default prototypes and whatnot. > I think so. Thanks for checking things over! -Boris
Received on Tuesday, 25 February 2014 19:57:55 UTC