- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 07 Oct 2010 23:08:41 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Garrett Smith <dhtmlkitchen@gmail.com>, "Mark S. Miller" <erights@google.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 Oct 7, 2010, at 10:49 PM, Cameron McCormack wrote: > 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]]. And in fact, some built-in objects have behavior "when called as a constructor" which cannot be explained as the 13.2.2 [[Construct]] algorithm invoking their [[Call]] behavior. One example is the String constructor. The spec doesn't seem to explicitly define its [[Call]] and [[Construct]] internal properties, but this is the only sane interpretation. Regards, Maciej
Received on Friday, 8 October 2010 06:09:15 UTC