W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 8 Oct 2010 17:05:05 +1300
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: "Mark S. Miller" <erights@google.com>, Maciej Stachowiak <mjs@apple.com>, James Graham <jgraham@opera.com>, Travis Leithead <travil@microsoft.com>, Simon Pieters <simonp@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, annevk@opera.com
Message-ID: <20101008040504.GA537@wok.mcc.id.au>
Garrett Smith:
> ECMA-262 [[Construct]] requires the target object to have a [[Call]]
> property. It appears that you may have been misled by Maciej
> Stachowiak's comment:
> "Another possibility when there are no legacy constraints is to not
> implement [[Call]], so that there is only one way to invoke the
> constructor."
> The problem with that statement is that the algorithm for
> [[Construct]] invokes the object's [[Call]] property and so if the
> new'd object does not implement [[Call]], then a TypeError would
> result.

Is that just for native Function objects, or for host objects as well?
I see that the native Function object [[Construct]] (section 13.2.2 of
ES5) calls [Call]], but I couldn’t find a requirement that host objects
that implement [[Construct]] must also implement [[Call].

For consistency, since that’s always the case with the built-ins, it’s
probably a good idea.  Of course, you could always implement [[Call]] as

  1. Throw a TypeError.


> And so it can be said that any object which implements [[Construct]]
> must also implement [[Call]]. Though the reverse is not true, for
> example, there are built-in functions specified to not implement
> [[Construct]] e.g. parseInt, Function.prototype.


Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 8 October 2010 04:05:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC