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

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