- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 14 Nov 2014 14:11:13 -0500
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 11/14/14, 1:48 PM, Allen Wirfs-Brock wrote: > (when ready the ES6 spec, it is import to know that "current realm" is associated with function objects, not with abstraction operations. Yes, I'm aware of all this. > ok, I get it. It's essentially an lazy accessor Somewhat. > as the set of contexts could conceptually have been pre-populated with all possible context types when the HTMLCanvasElement was instantiated. It's not obvious to me whether this is actually equivalent in this case, since some of those creations might have side-effects. But on a high-level conceptual level, yes. > If you think about it this way, then I would expect that all of the context values would be associated with the same realm as the HTMLCanvasElement instance. Right. Except of course ES has no notion of objects being associated with Realms. ;) So for Web IDL, to support use cases like this, it seems like we do in fact want to associate objects to Realms at creation time. Once we do that, a viable path forward might be that a getter or method that is not marked [NewObject] but creates a new object and caches it will use the Realm of "this" for the thing it creates. A method marked [NewObject], which therefore guarantees that each call creates a new object, would associate that new object with the Realm of the method itself. All that by default, of course. Individual specs would be able to override somehow (e.g. I'm pretty sure that document.createElement needs to put the element in the Realm of the document for web compat, even though it's a [NewObject] method). Does this seem like a reasonable approach? -Boris
Received on Friday, 14 November 2014 19:11:41 UTC