Re: Would it make sense for Web IDL [[Call]] to do the current execution context munging that ES6 functions' default [[Call]] does?

On Aug 28, 2014, at 9:43 AM, Boris Zbarsky wrote:

> Right now ES6 seems to have the following abstract operations defined:
> 
> 1)  GetGlobalObject.  This will get the global of the current execution context.
> 
> 2)  GetFunctionRealm.  This takes a function object and returns its realm.
> 
> That's it.
> 
> So if a Web IDL function wants to get at its own global it has to call GetFunctionRealm on itself and then extract the global from the Realm. There is no abstract operation for this last bit; it'd just have to poke at internal slots.
> 
> If Web IDL functions munged the current execution context, we could just GetGlobalObject() to do the right thing in spec algorithms as needed.
> 
> Furthermore, I suspect that suspending the current execution context on function entry is in fact needed to properly interop with some ES features...
> 
> -Boris
> 

I think we need to be careful to make sure that we are talking about the same thing when we say "execution context".

Every function object (both ES and "native") is supposed to be associated with the specific Realm in which it was created. Each Realm has its own global object association.  So, if you have a reference to a function object, you can always find its associated global object via the function's realm association. So far, this is all independent of execution contexts

ES6 defines execution context here:  [1]. ES execution contexts are typically created when a function (whether ES code or "native" code) is [Call]]'ed.  ES execution contexts always contain a [[Realm]] reference, whose value is the Realm within which the associated function was created.

If pseudo-code has a reference to a function it can always retrieve the associated global object. However, in few places in the ES spec. abstract operations that don't have a reference to a function need to access the global object used within the active execution context.  That's what  GetGlobalObject [2] does.  It retrieves the current global object via the active execution context.

Because, the ES algorithms almost always are operating with an active execution context, they could use GetGlobalObject even when they have an explicit reference to the currently executing functions.  In practice, there is only a handful of places within the ES spec. that need to explicitly reference the Global Object so how it is expressed isn't much of an issue. Within ES6, the Realm of the active execution context is a much more important concept than the current global object.

Not sure what you mean by "If WebIDL function munged the current execution context".  this is what make me think you may mean something different than the ES6 definition. Also. I don't understand the "suspending the current execution context on function entry" statement.  From an ES perspective I expect that every [[Call]] to a WebIDL function suspends the calling execution context and establishes a new execution context in conformance to [3].  If WebIDL functions are going to be specified using ES6 spec. abstract operations, those operations will generally assume that there is an active execution context corresponding to the most recently [[Call]]'ed function 

Allen

[1]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-execution-contexts
[2]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-getglobalobject 
[3]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist