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:11:13 -0500
Message-ID: <546653D1.80300@mit.edu>
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

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