Re: Weird spec hole in ES3 and ES5

> What does "Error.apply({}, [])" do? We ran into this issue in trying  
> to fix a Caja bug. Of course, the real question for Caja must be  
> what do browsers do today, which we can test. But I was curious what  
> the spec said. From the way the Ch15 constructors are documented, I  
> think in general we can't tell. ES3 and ES5 both seem to suffer from  
> the same hole in the spec language.
>
> The documentation of .call(), .apply(), and .bind() are in terms of  
> invoking an internal [[Call]] (or for .bind(), also a [[Construct]])  
> property). However, the Ch15 constructor documentation doesn't  
> actually mention these internal property names. It explains instead  
> what happens when a constructor is called as a constructor (with  
> "new"), which is probably adequate to infer the behavior of the  
> [[Construct]] property. And it explains what happens when a  
> constructor is called as a function. But it is not clear from the  
> latter what, if anything, one should infer about the constructor's  
> [[Call]]. In particular, what should happen when .call(), .apply(),  
> or .bind() causes a Ch15 constructor's [[Call]] to be invoked with a  
> thisArg that either 1) does not inherit from that  
> constructor's .prototype, or 2) does not have the [[Class]] that the  
> constructor would normally place on the newly constructed object?

>
> This same problem arises if a Ch15 constructor is called as a  
> method. What should "({foo: Error}).foo()" do?
>
>
> One interpretation of "called as a function" in the Ch15 constructor  
> documentation is that the thisArg (since it is never mentioned) is  
> always ignored. This seems consistent with the behavior I just  
> observed on FF3.0.10, Safari 3.2.3, and Chrome 3.0.189 on the Mac.  
> This seems fine, except that it means one cannot use the normal  
> "subclassing"ish pattern for defining new error constructors that  
> extend Error, since Error will ignore the normal constructor  
> chaining. Is this intended?