On Fri, Feb 14, 2014 at 7:40 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
[...]

>
> 1) Extend the ES5 semantics to include the new declaration forms.  For
> example:
>
> (function() {
>       eval("let answer=42");
>       console.log(answer);  // 42
> })();
>
> 2) Use the strict mode binding semantics  if the eval code directly
> contains any of the new declaration forms:
>
> (function() {
>       eval("
>           var answer=42;
>           let forceSeprateEnvironment = true;
>        ");
>       console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> 3) Combination.  use ES5 non-strict binding semantics for var/function
> declarations but place let/const/class bindings into a per eval environment:
>
> (function() {
>       eval("
>           var answer=42;
>           let localToEval = true;
>        ");
>       console.log(answer);  // 42
>       console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
>
> It would certainly be possible to specify #1, but I don't like it. Other
> than for the global environment it would be cleaner if the new block
> scope-able declarations  were never dynamically added to the environment.
>
> I think either #2 or #3 is plausible.  #2 is a simpler story but
> introduces a refactoring hazard. If you have some existing eval code that
>  defines some "global" functions or variables, then simply adding a
> let/const/class declaration to the eval code ruins those global
> declarations.
>
> I prefer the simplicity of #2, but I also worry about the WTF impact it
> might have on evolving existing code.
>
> Can we get away with #2, or are we going to have to go with #3?  Are there
> other alternatives?
>

I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I
find it least surprising. "var"s hoist out of blocks. In non-strict code,
"function"s leak out of blocks in ways that are hard to explain. I can
understand non-strict direct eval as being block-like, in that "var" and
"function" leak out of them, but all the reliably block-local declarations
stay within the direct eval.

Also, I buy the refactoring issue. It's like the problem with micro-modes:
bizarre and unexpected non-local influences.


-- 
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to