"static" in C means "a variable that has been allocated statically —
whose lifetime extends across the entire run of the program"
"static" in Java means "a property or method appertaining to class
itself and not to class instances"
"Static" in Visual Basic / VBA means "a function or sub that retains
its internal state between calls"
Now let's make a global definition "what does static mean In The
Programming" and we will get the same eclectic nonsense so far
demonstrated in this thread.
Let's make slow step by step:
1) We don't dive a damn what "closure" would mean in C, C++, Java,
Perl, PHP and ad infinitum. We only care what "closure" means in any
ECMA-262 compatible implementation of the programming language here
and further conventionally referred as "Javascript" (with only first
letter capitalized).
2) In Javascript "a closure" is a function with its internal call
state fully retained even after the execution of that function is
ended. It can be achieved by using "an inner function". Inner
functions are *not* closures and they do not automatically create
closures with outer functions. Yet inner functions is the instrument
to form closures in Javascript if such programmatic decision is made
by the programmer.
/////////////////
// Not a closure:
function outer() {
return inner('Hello');
function inner(x) {
return x + ' World!';
}
}
window.alert(outer()); // "Hello World!"
/////////////////
/////////////////
// A closure:
function outer() {
var x = 'foobar';
return inner;
function inner() {
return x;
}
}
var myClosure = outer();
window.alert(myClosure); // 'foobar'
/////////////////
So the key points of Javascript closures are:
a) the outer function execution context is fully retained even after
exiting the outer function
b) the inner function is the only gates to access in any way the
retained context
c) the retained context exists and garbage collection exempted until
at least one reference to the inner function exists.
This definition differs from other programming languages. For instance
in Perl a closure is any state of things when one sub contains another
sub and they are using each other. See for instance "Perl Cookbook" by
Tom Christiansen, Nathan Torkington, the chapter "10.16 Nesting
Subroutines". So in some languages "a closure" may equal to "nested
functions". This is why it is important to remember the step 1 at the
beginning and what we do give a damn and what we don't.
3) The "founding fathers" of CC scoping were rather unclear with their
definition of closure. Most importantly the key point (a) from above
is fully escaped from their attention. They are concentrated on one
particular outcome of (a)+(b): the possibility of a restricted access
to variables of the outer function.
Douglas Crockford
http://www.crockford.com/javascript/private.html
"... JavaScript has closures. What this means is that an inner
function always has access to the vars and parameters of its outer
function, even after the outer function has returned."
Richard Cornford
http://classic-web.archive.org/web/...totes.demon.co.uk/js_info/private_static.html
"It is possible to form a closure that included the class constructor
and local variables that would server as private class members by
making a one-off inline function ..."
Back in 2006 I asked Richard Cornford if it was the original
underestimate of the daemon they are calling or it was a conscious
decision with benefits - as they saw it - well overcoming any possible
drawbacks. I understand that the latter, see his answer at "Function
declaration inside other function" tread:
http://groups.google.com/group/comp.lang.javascript/msg/b44b1b7d902a124a
4) Till rather recently CC scoping was easy to bypass on Gecko
platforms by using non-standard __parent__ function property. It was
finally removed only in the last year:
http://whereswalden.com/2010/05/07/...special-__parent__-property-has-been-removed/
Until then one could access the outer activation object and its
variable by addressing innerFunctionReference.__parent__.whateverINeed
The exception was made for variables with names starting with
underscore: _likeThis. Such variables would not be visible to
__parent__. This is what David Mark mentioned as a "story of one
clueless programmer". It was much fun to read it to see the "broken
telephone game" in action
Now after we have figured out what closures are in Javascript we can
actually start answering OP's question. Is it a closure? No, because a
DOM object is not a function and there is not activation object to
retain. Can it form a circular reference or other garbage collection
troubles in some version of some browser? A careful investigation
needed.
