Weird spec hole in ES3 and ES5
mjs at apple.com
Thu Jul 2 16:47:52 PDT 2009
On Jul 2, 2009, at 10:29 AM, Mark S. Miller wrote:
> On Thu, Jul 2, 2009 at 9:26 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com
> > wrote:
> Because built-in constructors are not (necessarily) implemented in
> ECMAScript code they are not required to use the definitions of
> [[Call]] and [[Construct]] given in 13.2.2 and 13.2.3. Arguably the
> "Constructor Called as a Function" and "called as part of a new
> expression" sections of chapter 15 are specifying the behavior of
> custom [[Call]] and [[Construct]] internal methods for each built-in
> The problem is that .call(), .apply(), and .bind() are specified in
> terms of [[Call]], so unless the connection is somehow made, it
> technically becomes unspecified how native constructors respond to
> these reflective operations.
> AFAIK, the observed behavior across browsers is consistent with the
> theory that "called as a function" actually documents the
> constructor's [[Call]] method.
> I'll see if can find a way to clarify this in the introduction to
> chapter 15.
> Some introductory text there would be adequate. No need to propagate
> local changes.
> In my initial message, I was also confused about whether "called as
> a function" was meant to cover cases such as
> foo.Error(x, y)
> which I normally distinguish by saying "called as a method". If this
> is not unclear in the context of the rest of the ES5 spec language,
> no further explanatory note is needed, but may be helpful to readers
> as confused as I.
In ECMAScript terms, what we informally call a "method call" is a kind
of function call that explicitly specifies the "this" object to use
for the call. So it's pretty clear to me that in the case of
foo.Error(x, y), Error is being called as a function.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss