indirect eval spec too severe?

Maciej Stachowiak mjs at apple.com
Fri Jan 23 02:02:07 PST 2009


On Jan 18, 2009, at 12:47 PM, Mark S. Miller wrote:

> The Mountain View draft says:
>
> 15.1.2    Function Properties of the Global Object
> 15.1.2.1    eval (x)
> When the eval function is called with one argument x, the following  
> steps are taken:
> [...]
> If the value of the eval property is used in any way other than a  
> direct call (that is, other than by the explicit use of its name as  
> an Identifier which is the MemberExpression in a CallExpression), or  
> if the eval property is assigned to, an EvalError exception may be  
> thrown.
>
> 15.1.2.1.1    Strict Mode Restrictions
> If strict mode code uses the value of the eval property any way  
> other than as a direct call (that is, other than by the explicit use  
> of its name as an Identifier which is the MemberExpression in a  
> CallExpression), or if the eval property is assigned to, an  
> EvalError exception is thrown.
>
>
> I believe this spec is too severe, both for nonstrict and strict  
> code. My sense of the committee consensus is that an indirect eval  
> call should be unconditionally allowed, in which case the execution  
> context should be the global execution context, as already  
> adequately specified in 10.4.2. (In the committee's conversations,  
> we've referred to the "direct calls" of the spec language as the  
> "eval operator", and the spec's "indirect calls" as the "eval  
> function". I'm happy with either terminology.)

Certainly, actually raising exceptions in the cases cited is not  
compatible with the Web, and is not much easier than treating indirect  
calls (or apparently direct calls that end up being just normal calls)  
as calls. That's what ES4 required and WebKit at least implements this  
behavior.

Regards,
Maciej



More information about the Es-discuss mailing list