3 ms·
> Only variables used in the closure are allocated into the closure I'm not sure that's true. Look at the following code: var x = 123; var f = function(x
by Udo 12y ago
> Only variables used in the closure are allocated into the closure
I'm not sure that's true. Look at the following code:
var x = 123;
var f = function(xname) {
eval('console.log('+xname+');');
}
f('x');
It's a dynamically named variable. Clearly, f() has access to the entire context that surrounds it, not just the objects explicitly used in the function code. In this example, the compiler could not possibly have known I was going to access x.
This means in Javascript, as well as in Ruby, when you hand a closure to my code, I can access the entire environment of that closure.
Contrast that with Lua, for example, where the compiler does indeed check whether an outer variable is being used and then it imports that variable from the context only.
PHP does it most explicitly, forcing the developer to declare what outer objects they want to have available within the function.
- Sheepshow 12y agoIn your example, X is still in scope when f('x') is called. It doesn't require closure to work.
- Udo 12y agoI think you misunderstand what I'm trying to say. The point is not that x should be out of scope (why would it be?) The original assertion by curveship was that the outer context is not kept alive for the function, and that f() only gets access to the variables it explicitly imports from the outer context. And I thought this might be wrong, so I cooked up the example. Again, this is not about scope. This is about the fact that the function itself keeps a reference to the entire context it was created in, as opposed to just the things it explicitly imports. In this, it appears, Javascript works exactly as Ruby, which again makes the entire outer context available through the binding facility. I'm sorry if that wasn't clear from my description.
- curveship 12y ago> In this example, the compiler could not possibly have known I was going to access x. Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.
- Udo 12y ago> Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. Wow, so there is actually special handling in the engine for this? So it does static analysis whenever it can, but not in these two cases?
- curveship 12y agoYes, the V8 compiler bails out of several optimizations if your function uses eval. You can see this in the profiler: functions which V8 wasn't able to optimize will have an alert sign next to them, and if you click it, it'll tell you what the issue was.
- Udo 12y agoVery cool, thanks for clearing that up!
- anonymoushn 12y agoThis is a bit troublesome! function f() {var x = 99; return function(a,b) {return a(b)};} f()(eval, 'console.log(x);') ReferenceError: x is not defined function f() {var x = 99; return function(a,b) {return eval(b)};} f()(eval, 'console.log(x);') 99 undefined
- curveship 12y agoYep, this is as per spec: http://www.ecma-international.org/ecma-262/5.1/#sec-10.4.2 http://www.ecma-international.org/ecma-262/5.1/#sec-10.4.2 . "Indirect" calls to eval (i.e. assigning eval to another variable, like you did by passing it as a param) are evaluated in terms of the global environment. "Direct" calls, like in your second example, use the local environment.
- coldtea 12y agoYes, and in articles describing it (v8), they explicitly warn you to not use "eval" or "with" for the performance impact.