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

On 8/28/14, 1:37 PM, Allen Wirfs-Brock wrote:
> If pseudo-code has a reference to a function it can always retrieve the
> associated global object.

Right.  The problem is having that reference.

For typical spec prose specifying the guts of a Web IDL function, it 
doesn't seem obvious to me that the spec prose has such a reference.  It 
could obviously always handwave with things like "this function" or some 
such, but it seems like it might be a good idea to not do that.

>   That's what  GetGlobalObject [2] does.  It retrieves the current
> global object via the active execution context.

Yep.  My question is whether it would make sense to make 
GetGlobalObject() do the right thing when used in the guts of a Web IDL 
function.  As things are specified right now, I believe it will return 
the Realm of the code that called the Web IDL function, no the Realm of 
the Web IDL function itself.

> Within ES6, the Realm of the active execution context is a
> much more important concept than the current global object.

Sure.  That involves the concept of "current Realm", which is itself 
tied to the "running execution context", right?

> Not sure what you mean by "If WebIDL function munged the current
> execution context".

What I had meant was performing the steps at 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist 
(thank you for the link; I was looking at 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-function-objects-call-thisargument-argumentslist 
before that, which has a bunch of complications that don't seem relevant 
here).

> 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].

Ah, I see.  I had recalled Web IDL defining its own [[Call]] for 
methods, but looks like it does not.  It just talks about "a Function 
object whose behavior is as follows".  So it should just explicitly say 
this is a "built-in Function object" and then I think we're good, 
mostly, right?

I say mostly, because there _are_ some cases where Web IDL defines its 
own [[Call]].  Specifically, for constructors and legacycallers.  Is 
there a way those [[Call]] definitions could just have the steps of 
#sec-built-in-function-objects-call-thisargument-argumentslist performed 
without copy/pasting them?

> 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

Yes, exactly what I'm trying to make sure actually happens.

-Boris

Received on Thursday, 28 August 2014 18:04:11 UTC