In what ways does the following "eval" regularity break?
Brendan Eich
brendan at mozilla.com
Thu Oct 30 08:35:02 PDT 2008
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
More information about the Es-discuss
mailing list