Re: Determining what prototype should be used for an object

On Nov 14, 2014, at 11:11 AM, Boris Zbarsky wrote:

> 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.  ;)

You can capture a realm reference in an internal slot of the object when it is created  If you were coding this ES you might do so by capturing a closure as function values always have a realm association.
> 
> 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?
 
I don't really feel very good about by default tying allocation behavior to the realm of the this value rather than the realm of the current function.  That just isn't how ES6 works and it's not at all clear to me that it is a reasonable default. 

In all honesty, cases where somebody intentionally uses call/apply to force the realm of the method to be different from the realm of the this value are weird enough that it isn't clear to me that they are worth explicitly worrying about.  In ES6 we would generally handle such cases simply by realizing that you can always determine from the spec. exactly what realm you are going to get, even in such cases.  As long as implementors do what the spec. says, people who do such strange things can expect interoperable results but it is up to them to determine whether their weird ness makes any useful sense. 


Allen

Received on Friday, 14 November 2014 19:40:49 UTC