In what ways does the following "eval" regularity break?

[Brendan Eich]

I don't see the point in adding new functions (global functions,  
presumably), at least not without opt-in (which will make such  
additions even less usable). JSON is not out of the woods as a  
breaking change in ES3.1. ES3.1 otherwise tries to put new properties  
in Object to avoid dancing with object-detecting scripts that  
conditionally supply their own JSON, localEval or whatever.

JS programmers have better best-practices guides now. Stupid eval  
tricks remain but the ones I see are in old code. Browser intersection  
semantics make indirect eval global, otherWindow.eval scope to a  
different global, and eval called as an "operator" (with parentheses  
around its argument, of course) local in context. Changing this is  
going to be hard, possibly harder than injecting new names into the  
global object.

Between a rock and a hard place the least we should do (i.e., what  
fits in 3.1) is to go straight ahead: specify indirect, other-global,  
and operator eval. The wiki has discussion and draft spec language  
from ES4.

/be

On Oct 30, 2008, at 6:41 AM, liorean wrote:

> Why not introdouce one localEval that evaluates in local scope but
> does not allow modifying the local scope, a globalEval that evaluates
> in the global scope, and maybe an expressionEval which allows
> anonymous function literals and parses { as the beginning of an object
> literal instead of a block statement?
>
> That should cover current usage of eval except for the case of wanting
> to inject variables into the scope. Which would mean dropping eval in
> strict mode isn't that awful an idea.
> -- 
> David "liorean" Andersson
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss