Yeah, you could test this in the first example by replacing the string 'interval' with something like "alert(str.length)", and then redefining console.log=eval.
e: nm, I missed pcwalton's point -- when you call eval indirectly it isn't accessing the same scope. So redefining console.log couldn't access local variables like str. (I don't think?)
Comments
Nice! You've explained why this 'memory leak' could be by design - blame eval.
In fact, Chrome GC-ing unreferenced variables could break eval if they didn't cover that case.
Only direct `eval` though. As long as you don't see any calls to symbols named `eval`, you can implement this optimization.
See http://stackoverflow.com/questions/8694300/how-eval-in-javas...
Yeah, you could test this in the first example by replacing the string 'interval' with something like "alert(str.length)", and then redefining console.log=eval.
e: nm, I missed pcwalton's point -- when you call eval indirectly it isn't accessing the same scope. So redefining console.log couldn't access local variables like str. (I don't think?)
Correct. Not only is eval not a good idea in general, but it's a very weird beast in javascript. See http://perfectionkills.com/global-eval-what-are-the-options/ for a very complete exposition of its weirdness.