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

Re: Determining what prototype should be used for an object

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Fri, 14 Nov 2014 14:43:36 -0500
Message-ID: <54665B68.8050907@mit.edu>
To: Adam Klein <adamk@chromium.org>
CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 11/14/14, 2:32 PM, Adam Klein wrote:
> Are you proposing this just for Web IDL, or to associate all ES objects
> with a Realm at creation time?

Just for Web IDL, so that we can support lazy-creation APIs on arbitrary 
Web IDL objects.  The alternative would be to have specifications using 
Web IDL opt in to storing the Realm of the object, but I'm sort of 
aiming for something where web specifications don't have to talk about 
Realms unless they're doing something weird and unusual.

In implementation terms, of course, you may not need to associate a 
Realm/Global/whatever to all objects.  Or you may if, like Gecko, you 
allow the JS object to be GCed while the DOM object is alive and need to 
be able to recreate it correctly...

> 2) The V8 implementation of Object.getNotifier() (part of the
> Object.observe spec) does exactly this sort of "create an object from a
> prototype" thing, and it's become clear that we need to better-define
> what Realm the notifier is created in.

Ah, yes, this does exactly the lazy creation thing under discussion.

For what it's worth, SpiderMonkey currently associates all JS objects 
with a Realm, and we have no plans to change that (in fact, it's the 
basis for our security proxies), so for us the simplest thing to do 
would be to us the realm of the argument to getNotifier.  That is, to 
act as if the [[Notifier]] slot is filled at object creation time.

As http://wiki.ecmascript.org/doku.php?id=harmony:observe_internals is 
written right now, it would create the notifier in the Realm of the 
getNotifier method (or the observe() method, or unobserve(), whichever 
is called first) and the cache it, which I agree seems a bit dubious.

Received on Friday, 14 November 2014 19:44:05 UTC

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