closures in JavaScript

[MartinRinehart]

I've written a short article explaining closures in JavaScript. It's
at:

http://www.martinrinehart.com/articles/javascript-closures.html

I think I've understood. I look forward to your constructive critique.

 

[Thomas 'PointedEars' Lahn]

I've written a short article explaining closures in JavaScript. It's
at:

http://www.martinrinehart.com/articles/javascript-closures.html

I think I've understood. I look forward to your constructive critique.

- A closure is _not_ "a bundle of data and code that manipulates that data";
that is how you could describe an *object* (and often it is done so),
which has properties and methods (which are merely callable properties in
ECMAScript implementations) to operate on these properties.

A closure is instead a subroutine (function) that reproduces its
definition context when executed. This definition context would
contain what is called "bound variables" that can then be accessed
from within the subroutine when executed (cf. Wikipedia etc.)

- Inner functions, by which you mean function declarations within function
declarations, must be distinguished from function expressions that you
are using later in your article to create closures.

While both constructs can create a closure, the former cannot create
closures with bound "variables" that are created after variable
instantiation. In contrast to function expressions, function declarations
cannot be within a block statement, so they cannot be conditional (except
with evil[tm] eval()).

I find calling a function expression an "inner function" to be confusing
at best. That is a term that I would use only for nested function
declarations.

And while the Specification makes no statement regarding the nesting depth
of functions (be they declared or created through an expression), there is
most certainly a practical limit, stack size included. IIRC we have
discussed this here before.

- I disagree with your sentiment that JS/ES was more pythonic than Python;
knowing both languages quite well, when it comes to power of expression
ECMAScript implementations still have a lot to learn from Python.
Incidentally, they are beginning to: read Brendan Eich's blog regarding
this; then consider Array comprehensions being supported since JavaScript
1.7 (Gecko 1.8.1/Firefox 2.0.x), which is but a Python copycat.

- The statement "In addition to explicitly declared parameters and vars,
there are other things. You can access some of them directly, such as
this and arguments." is wrong, because neither of the mentioned features
are either parameters or variables.

`this' is a keyword and a (Reference) value that refers to the calling or
constructed object. `arguments' is a property (of the Activation/Variable
object).

- The statement "Other parts, such as the activation object and the
execution context are also present, but you cannot access them from
JavaScript." is wrong in its absoluteness, because you can access the
Activation Object of the global execution context with `this' because
the Global object is also the Variable Object of this context.

The execution context as such is not anything that is supposed to be
accessible in code because it is merely a theoretical construct.

- "When outer() returns a function it also returns a copy of its execution
context." No, it does not, that's nonsense; because again, the execution
context is only a theoretical construct.

Instead, when the Function object is created in outer() it would need to
retain some information about which of the "variables" (properties) in it
are bound to the execution context of outer() and which are not; probably
a copy of or a reference to the Variable Object of the execution context
created with the previous outer() call.

What is returned is a reference to the Function object. Whether or not
that Function object retains a copy of or a reference to the Variable
Object of the execution context created with the previous outer() call
instead, remains to be seen; I would presume this to be
implementation-dependent, although it would be more efficient to use
a reference.

- As for your example, where is `init()'?

- As for your summary, where is `grow'?


HTH

PointedEars

 

[Thomas 'PointedEars' Lahn]

- The statement "In addition to explicitly declared parameters and vars,
there are other things. You can access some of them directly, such as
this and arguments." is wrong, because neither of the mentioned features
are either parameters or variables.

`this' is a keyword and a (Reference) value that refers to the calling or
constructed object. `arguments' is a property (of the Activation/Variable
object).

Ignore that; I misunderstood your statement.

However, I think it is wrong to say that that (function) parameters are
declared: function *expressions* are _not_ *declarations* and still have a
parameter list (better: arguments). I am not sure what to use instead;
"Definition"/"defined" sounds better to me here.


PointedEars

 

[Jorge]

I've written a short article explaining closures in JavaScript. It's
at:

http://www.martinrinehart.com/articles/javascript-closures.html

I think I've understood. I look forward to your constructive critique.

Martin,

I don't agree with this:

"Some things are worth repeating: When outer() returns a function it
also returns a copy of its execution context. That is not a reference
to its execution context, it is a copy. (Probably it's a reference to
a copy, but that's an implementation detail we don't need to worry
about.) That is why I added "Sort of." when I said the closure had
access to the vars (and so on) of the outer function. It really has
access to a new set of vars (and so on) that are an exact copy of the
outer function's execution context at the time the closure was
returned by outer()."

I think that the execution context of the outer function is not copied
nowhere, it's just that it's not destroyed, it's kept in memory for as
long as the references to inner functions exist. It will last as long
as those references. Consider this example:

<html><head>
<script>
window.onload= function () {
var e, capturedInAClosure= 0;
document.body.appendChild(e=
document.createElement('button')).innerHTML= "doIt";
e.onclick= function () { e.innerHTML= ++capturedInAClosure };
document.body.appendChild(e=
document.createElement('button')).innerHTML= "doItAgain";
e.onclick= function () { e.innerHTML= ++capturedInAClosure };
document.body.appendChild(e= document.createElement('p')).innerHTML=
capturedInAClosure;
};
</script>
</head><body></body></html>

2 references to 2 inner functions remain after returning from
window.onload: doIt.onclick() and doItAgain.onclick(). Both point to
the very same 'capturedInAClosure' var, end the very same 'e'. So they
are sharing the execution context of window.onload. It's not 'a copy'
nor a 'new set of vars that are an exact copy' of the outer function.

Don't you think so ?

 

[Jorge]

2 references to 2 inner functions remain after returning from
window.onload: doIt.onclick() and doItAgain.onclick(). Both point to
the very same 'capturedInAClosure' var, end the very same 'e'. So they
are sharing the execution context of window.onload. It's not 'a copy'
nor a 'new set of vars that are an exact copy' of the outer function.

Also, everytime the outer function is called, a new execution context
is created:

<html><head>
<script>
window.onload= function () {
var e, capturedInAClosure= 0;
document.body.appendChild(e=
document.createElement('button')).innerHTML= "doIt";
e.onclick= function () { e.innerHTML= ++capturedInAClosure };
document.body.appendChild(e=
document.createElement('button')).innerHTML= "doItAgain";
e.onclick= function () { e.innerHTML= ++capturedInAClosure };
document.body.appendChild(e= document.createElement('p')).innerHTML=
capturedInAClosure;
if (!arguments.callee.inited) {
arguments.callee.inited= true;
setTimeout(window.onload,0);
setTimeout(window.onload,0);
setTimeout(window.onload,0);
}
};
</script>
</head><body></body></html>