- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 14 Nov 2014 14:43:36 -0500
- 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. -Boris
Received on Friday, 14 November 2014 19:44:05 UTC