- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Thu, 7 Oct 2010 20:45:51 -0700
- 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 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. 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. Garrett
Received on Friday, 8 October 2010 03:46:23 UTC