（JS）闭包需要函数内部的函数 [英] Does a (JS) Closure Require a Function Inside a Function

问题描述

我对闭包的内在概念有点困难。我得到了基本的想法，但这里的事情：我认为，技术上，每个Javascript函数内部都有一个闭包。引用维基百科：

在计算机科学中，闭包（也称为词法闭包，函数闭包
或函数值）以及引用该函数的非本地名称（自由变量）的
环境。
这样的函数被称为自由变量。

函数，他们是关闭到你的代码的其余部分，所以我看到作为一个闭包。因此，根据我的理解：

 （function（）{var a = 1;}（））
  

是一个（非常有用的）闭包示例。或者，即使只是这样：

  function（）{var a = 1;} 
  

但是，我认为我的理解可能是错误的。其他人告诉我，为了成为一个闭包，它必须持有一个状态，所以，因为没有什么持续超出该代码，它不是一个真正的闭包。这表明你需要：

  function（foo）{foo.a = 1;} // bar.a = 1 
  

或甚至（以确保不可修改）：

  function（foo）{var a = 1; bar.baz = function（）{return a}}（bar）; // bar.baz（）= 1 
  

因此，从技术上讲实际上是无意义的，但是）上面的例子实际上是闭包的例子。并且闭包只需要是一个空格（即在JS函数内），其中可以存储不能从外部访问的变量，或者是持久化闭包定义的关键部分？

EDIT

只是注意到Stack Overflow上的closures标签的wiki定义：

闭包是一个第一类函数，它从定义的范围引用（关闭）
变量。如果关闭仍然存在
，它的定义范围结束后，它关闭的变量
将继续存在。

虽然SO wiki肯定不是最终权威，第一句似乎与我对这个术语的理解有关。第二句然后建议如何使用闭包，但它不像一个需求

。

编辑＃2

如果从这里不同的答案不清楚，维基百科答案和标签答案，似乎没有明确的共识是什么闭包甚至手段。所以，虽然我欣赏所有的答案，到目前为止，他们都有道理，如果你去与作者的定义闭包，我猜我真的在寻找是...有任何实际的权威的定义

解决方案

你被错误地引导误入歧途假设语句closure来自哪里。

在语言理论的上下文中，闭包的点是函数指的是声明在其自身定义之外的 变量。它是否具有内部变量，或内部变量不可见从外部是无关紧要的。换句话说，它是从函数到其定义环境看到 out ，而不是从函数外部看到 。

为什么是奇怪的话，那么？看看你最后一个例子中的函数：

  bar.baz = function（）{return a} 
  

此函数包含未定义的变量 a 函数体本身。它是函数体的自由变量，在定义中排序一个空洞。我们不能通过一些无关的手段不知道身体中的标识符 a 是什么变量来执行函数。在运行时间形成闭包，通过引用适当的变量来对这个开放函数体进行配对，从而在定义中关闭 。这就是名字来自哪里。

（如果你想要完全的技术解释，基本的概念是在lambda演算中的一个闭合只有闭合的术语具有独立的意义。闭包是一个（通常编译的）非闭合的源代码片段的组合，以及使它表现得像闭合术语的上下文信息

<$ p

$ p> function（）{
var blah;
//这里的代码
}（）;


点是不是当然，但它不会为你做任何有趣的事情），而是为 blah 变量创建一个 local scope 。局部范围在概念上与闭包完全不同 - 事实上除了Javascript之外，大多数C-lookalikes将在每个 {} 块中创建它们，根本没有关闭。

I'm having a little difficulty with the inherent concept of a closure. I get the basic idea, but here's the thing: I thought that, technically, there "is a closure" inside every Javascript function. To quote wikipedia:

In computer science, a closure (also lexical closure, function closure or function value) is a function together with a referencing environment for the nonlocal names (free variables) of that function. Such a function is said to be "closed over" its free variables.

So since you can define variables inside a function, they are "closed off" to the rest of your code, and so I see that as a closure. Thus, as I understand it:

(function(){var a = 1;}())

Is a (not very useful) example of a closure. Or heck, even just this:

function(){var a = 1;}

But, I think my understanding might be wrong. Others are telling me that for something to be a closure it has to persist a state, and so since nothing persists beyond that code it's not really a closure. That suggests that you need to have:

function(foo){foo.a = 1;}(bar); // bar.a = 1

or even (to ensure un-modifiability):

function(foo){var a = 1; bar.baz = function() { return a}}(bar); // bar.baz() = 1

So, technically speaking (I know several of the examples are practically speaking pointless, but) which of the above examples are actually examples of closures. And does a closure just have to be a space (ie. inside a JS function) where variables can be stored that can't be accessed form outside, or is persistence a key part of a closure's definition?

EDIT

Just noticed the wiki definition for the "closures" tag on Stack Overflow:

A closure is a first-class function that refers to (closes over) variables from the scope in which it was defined. If the closure still exists after its defining scope ends, the variables it closes over will continue to exist as well.

While the SO wiki is certainly no final authority, the first sentence does seem to correlate with my understanding of the term. The second sentence then suggests how a closure can be used, but it doesn't seem like a requirement.

EDIT #2

In case it isn't clear from the varying answers here, the wikipedia answer, and the tag answer, there does not seem to be a clear consensus on what the word "closure" even means. So while I appreciate all the answers so far, and they all make sense if you go with the author's definition of closure, what I guess I'm really looking for is ... is there any actual "authoritative" definition of the word (and then if so, how does it apply to all of the above)?

解决方案

You're being led astray by a wrong assumption of where the word "closure" comes from.

In a language-theoretic context, the point of a closure is that the function can refer to variables declared outside its own definition. It is immaterial whether it has internal variables, or that the internal variables are not visible from outside. In other words it is about seeing out from the function to its definition environment, not about seeing in from outside the function.

Why the weird word, then? Look at the function in your last example:

bar.baz = function() { return a }

This function contains a mention of the variable a which is not defined in the function body itself. It is a "free" variable of the function body, sort of a "hole" in the definition. We cannot execute the function without knowing, by some extraneous means, what variable the identifier a in the body refers to. Forming a closure at run-time pairs this "open" function body with a reference to the appropriate variable, thereby closing the hole in the definition. And that's where the name comes from.

(If you want the completely technical explanation, the underlying concept is that of a "closed" term in the lambda-calculus, which means one that has no free variables. Only closed term have independent meanings. A closure is then the combination of a (usually compiled) non-closed piece of source code, together with the contextual information that lets it behave like it was a closed term, and therefore be executable).

Addendum: In the common idiom

function() {
   var blah;
   // some code here
}();

the point is not to get a closure (you will get one, of course, but it doesn't do anything interesting for you), but to create a local scope for the blah variable. A local scope is conceptually quite a different thing from a closure -- in fact most C-lookalikes other than Javascript will create them at every {} block, whereas they may or may not have closures at all.

这篇关于（JS）闭包需要函数内部的函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！