4

I see in the code or sometimes people talk about it, for some JavaScript code:

(function() {
    var something;

    function someFunction() { 
        // some code here
    }

    // do something

}());

That's an "Immediately Invoked Function Expression", or IIFE. I often hear people say, "yeah, do it in a closure", or "do this in a closure" in the code comment -- as if a closure is "protecting the leak to the global space."

But is that the correct concept? I think it is a local scope, or an anonymous local scope, that is shield any local variables from leaking to the global scope. It really has nothing to do with a closure, which is a function with a scope chain. Sure, the anonymous function used for the IIFE is a closure, but it is not relevant here. If you say you want a closure, it is because you want the access to the current scope (and all scopes in scope chain). To say, shielding local variable to the global scope "by using a closure", is not a correct concept, is it?

Update: In any language that doesn't have closure, such as C, you can still do the exact same thing of shielding any local variables to leak into the global space. So it is not "closure" that is doing the job.

  • It's an odd phrasing but it's basically correct. I would typically call it "defining a module" or perhaps "encapsulating something". Normally the "// do something" would be "return object with some getters and/or setters for something", so that code outside the IIFE can only access or manipulate something using exactly the methods returned by the IIFE and nothing else. – Ixrec Jan 19 '16 at 0:15
2

I think it is a local scope, or an anonymous local scope, that is shield any local variables from leaking to the global scope.

Yes, that's precisely what it is. And because JavaScript doesn't actually have block scopes, the only way you can implement it is with functions. Hence, IIFEs.

To say that you are using a closure here is true, because the function expression creates a closure. Without that, your "local scope" would have no access to any other variables in the scope in which it is found. However, this is again something of an implementation detail — it's not core to the problem at the design level.

|improve this answer|||||
  • but the key point is, it is not a closure that is doing the job. If you use C or any language that doesn't have closure, you can still do this exact same IIFE technique. So to say you are doing it by "closure", is not a correct concept – nonopolarity Jan 19 '16 at 0:24
  • @太極者無極而生: Yep, pretty much true. People do things like that all the time, though. Consider how everyone calls the conditional operator the "ternary operator" just because it's often the only one in the language and misteaching is rife. (Though in some languages it's even worse: that has become the official name!!) – Lightness Races in Orbit Jan 19 '16 at 0:31
  • doesn't the name ternary operator make sense? + is a binary operator because it involves two operands, so the a ? b : c involves 3, so "ternary" – nonopolarity Jan 19 '16 at 0:40
  • 1
    @太極者無極而生: Yes, it is a ternary operator, but that is not the core point of what the operator does, which is: evaluate to an expression, conditionally. It's the same thing as the problem you have with "closure": your code is a closure, but that's not why you wrote it. – Lightness Races in Orbit Jan 19 '16 at 0:44
  • I would not even call this a closure, because whether it is a closure or not a closure (as in C), it does exactly the same thing. So why would you use the term "closure"? – nonopolarity Jan 19 '16 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.