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

Garrett Smith:
> So by "[[Construct]]" you meant something other than [[Construct]]
> defined in ECMA-262, or what? What you are calling "[[Construct]]" is
> apparently not the same thing specified in ECMA-262 r3, is that right?
> Using an existing and normatively-specified term to describe a new
> routine seems like a good way to spread confusion.

I meant [[Construct]] as in the internal property, in general, not the
specific algorithm used as its value for native Function objects.

> > 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]].
> 
> What do you base that on? And where is this other [[Construct]]
> specified? It is not necessary to specify a language extension here.

Based on the fact that nothing in ES5 states that host objects with a
[[Construct]] must also have a [[Call]].

> Language extensions just create more disparity between real ECMAScript
> and WebIDL ECMAScript. (That's bad.)

I don’t know if I would call them “language extensions”, as they would
be host objects that are valid/allowed according to the spec.  I agree
that the disparity between what can be implemented in native JS code and
what can’t should be reduced to be as small as possible.

> > I think this isn’t strictly needed, since I believe you can have host
> > objects that implement [[Construct]] but not [[Call]].
> >
> ECMA-262 specifies [[Construct]] which says otherwise.
> 
> Can you explain why you think this is so?

Because it is not required that that particular [[Construct]] algorithm
is used as the [[Construct]] for host objects.

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

Received on Friday, 8 October 2010 06:23:42 UTC