Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 7:03 PM, Brendan Eich wrote:

>
>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
>>>>
>>>> In other words, eval's this value must be the same as the global  
>>>> object that defined it, else we throw.
>>>
>>> What is the rationale for throwing in this last case, rather than  
>>> using the explicit base object (otherWindow) as |this|?
>>
>> I'm not necessarily advocating this particular behavior, just  
>> describing it (based on code inspection). I would guess one reason  
>> to throw is to avoid answering whether the |this| value should be  
>> otherWindow, or the window in which copyOfEvalFromYetAnotherWindow  
>> was originally defined. I have no problem with either of those  
>> alternatives, personally.
>
> The standard ECMA-262 semantics want otherWindow -- "bound method"  
> exceptions prove the rule. And eval is not a bound method of its  
> window. So otherWindow seems likely to be the standard behavior, but  
> I wondered if you had some deeper reason (IE compatibility?) for the  
> third case.

OK, I did some research in old revisions. We made the change to throw  
in the case of a rebound eval, in the course of adopting ES4-like  
eval() semantics: <http://trac.webkit.org/changeset/30871>

I think this was consistent with the ES4 "resurrected eval" proposal  
at the time:  <http://wiki.ecmascript.org/doku.php?id=proposals:resurrected_eval 
 >

"If a property reference o.eval references the eval property on a  
global object o, and the eval property has its original value, and the  
property reference is used as the MemberExpression on a  
MethodCallExpression... then the result shall be that the argument s  
is evaluated in the normal way in the context of that global object  
only... Every other use of the original value of the eval property  
apart from just passing it around is an error, and the implementation  
shall throw an EvalError if the eval function is called in any other  
context than the ones that are specified above."

I'm not aware of any compatibility reason for throwing EvalError in  
this case, and we did not do so before. I don't think we particularly  
care about this behavior either way.

Regards,
Maciej

Received on Wednesday, 18 November 2009 03:44:27 UTC