Re: [WebIDL] interface objects with [Constructor] and [[Call]]

Garrett Smith:
> My statement in the previous paragraph is regarding the algorithm for
> [[Construct]], as specified in ECMA-262. Were you discussing a
> different [[Construct]]?

Ah, I (mis-)interpreted it as a comment on all objects’ [[Construct]],
be they native or host objects.

> In ECMA-262, step 6 of [[Construct]] is:
> | 6. Invoke the [[Call]] property of F, providing Result(1)
> | as the this value and providing the argument list passed
> | into [[Construct]] as the argument values.
> 
> Understand that an object that implements [[Construct]] implements
> [[Call]]. What is not known is what either of those commands will do.
> That is what specification is for.

Indeed.

> How can an object implement [[Construct]] but not [[Call]]?

It can if it is a host object and it has a [[Construct]] which is
different from the one defined for native Function objects in ECMA-262.
Then there is no need for it to have [[Call]].

> I get what you're after here, you want to specify that certain
> constructors throw a TypeError if not invoked via [[Construct]]. So
> its just a matter of putting that into specification terminology.

I think this isn’t strictly needed, since I believe you can have host
objects that implement [[Construct]] but not [[Call]].

I’ll note though that Web IDL currently doesn’t say whether the
interface object is a native or a host object, but the requirement for
it to have a [[Construct]] in some cases but not [[Call]] would imply
that it needs to be a host object.


Anyway, it is moot.  If we stick with disallowing calling interface
objects to get a constructed object then I will make them implement
[[Call]] (and thus be native Function objects) for consistency with
built-ins.  If we change to allowing calling them, then it’s even more
consistent.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 8 October 2010 05:50:23 UTC