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

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 7 Oct 2010 20:45:51 -0700
Message-ID: <AANLkTikC2NCPZ75+V8Me+Q3YJ8DV8Wz1v3pu263bDvwR@mail.gmail.com>
To: "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
On 10/7/10, Cameron McCormack <cam@mcc.id.au> wrote:
> The spec currently requires a TypeError to be thrown, just because there
> is no [[Call]] defined for interface objects.  I was going to say that I
> agreed with the reasoning from Maciej and Jonas, but this argument has
> swayed me the other way:

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

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

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.

> Mark S. Miller:
>> When a normal function F ignores its "this" and returns an object,
>> prefixing
>> a call to F with "new" results in no change in behavior.

You can say that.

Received on Friday, 8 October 2010 03:46:23 UTC

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