Closures Explained

[MartinRinehart]

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

http://www.martinrinehart.com/articl...-closures.html

A big Thank You to PointedEars and Jorge for helping me get closer to
the truth.

[Lasse Reichstein Nielsen]

Jorge <jo***@jorgecha morro.comwrites :

On Oct 10, 5:38*pm, MartinRineh...@ gmail.com wrote:

"Some authors said (and this was where I got confused) that the
closure has access to the variables of the outer function. This is
sort of true. Really it has access to the variable's names and values
at the moment the closure is created."

This isn't clear enough... a bit messy.

It's also wrong. The closure has access to the actual variables, not
just their value at the time the closure was created, including any
change to the variable, before or after the closure was created.T

That's why the following doesn't work as most people expect it to:

for (var i = 0; i < 10; i++) {
setTimeout(func tion(){alert(i) ;},i*2000);
}

It alerts "10" all ten times.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jorge]

On Oct 10, 5:38*pm, MartinRineh...@ gmail.com wrote:

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

http://www.martinrinehart.com/articl...-closures.html

"Really it has access to the variable's names and values
at the moment the closure is created."

No 'memory effects': in this example there are 10 different inner
functions that survive after the outer (window.onload) function
returns. They are created at different times and at different values
of 'n'. But they all alert the same value: the value that n has in the
(left orphan by window.onload's return) execution context of the outer
function: 10.

See: http://jorgechamorro.com/cljs/020/

<script>
window.onload= function () {
var e, n;
for (n=0; n<10; n++) {
document.body.a ppendChild(
e= document.create Element('button '
)).innerHTML= n;
e.onclick= function () { alert(n) };
}
};
</script>

--
Jorge.

[Jorge]

On Oct 12, 12:13*am, Lasse Reichstein Nielsen <lrn.unr...@gma il.com>
wrote:

(...)
That's why the following doesn't work as most people expect it to:

*for (var i = 0; i < 10; i++) {
* *setTimeout(fun ction(){alert(i );},i*2000);
*}

It alerts "10" all ten times.

On Oct 12, 12:17 am, Jorge <jo...@jorgecha morro.comwrote:

>
(..) But they all alert the same value: the value that n has in the
(left orphan by window.onload's return) execution context of the outer
function: 10.

LOL :-)

--
Jorge.

[Dr J R Stockton]

In comp.lang.javas cript message <gc**********@r egistered.motza rella.org>
, Fri, 10 Oct 2008 18:23:40, dhtml <dh**********@g mail.composted:

>D. Flanagan himself has said that the Pocket Reference was "probably
out of date."
http://groups.google.com/group/comp....866b23771e3a75
e?dmode=sour ce

Any book user or buyer should check its publication date (the publisher
and the year should be added to the FAQ entries), and not expect it to
cover anything more recent.

Since most JavaScript is executed by an agent remote from the author, by
various browsers of various ages, an Internet author should be very wary
of using anything that is not in ISO/IEC 16262.

Pocket Flanagan 2, October 2002, should cover what is in ECMA 262.

For those Flanagans, the FAQ should link to index.html not toc.html;
index should link to toc.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[Peter Michaux]

On Oct 10, 8:44*am, David Mark <dmark.cins...@ gmail.comwrote:

On Oct 10, 11:38*am, MartinRineh...@ gmail.com wrote:

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

http://www.martinrinehart.com/articl...-closures.html

It gets off to a dubious start:

"I had the best books (Flanagan, Resig, Crockford)"

Flanagan has been proven clueless

I think "clueless" is incorrect and inappropriate. He knows a lot as
displayed many times in his book and I still find his book a useful
starting resource for most browser-related issues. Yes his book has
mistakes but that does not make him clueless.

Peter

[Peter Michaux]

On Oct 10, 10:06*am, MartinRineh...@ gmail.com wrote:

David Mark wrote:

"I had the best books (Flanagan, Resig, Crockford)"

Flanagan has been proven clueless and Resig's books belong in the
comedy racks (or on a bonfire.)

And there isn't much there. *This is a far superior article:

http://www.jibbering.com/faq/faq_notes/closures.html

Flanagan is listed in the FAQ as the best JavaScript book.

"best" is a comparative term.

The jibbering article is a good resource.

Peter

[Conrad Lender]

On 2008-10-12 19:49, John G Harris wrote:

>>Moreover, the language Crockford defines isn't JavaScript, or even
javascript. It's a language where you aren't allowed to do

... { ... { ... } ... } ...

Where does he say that?

In the syntax diagrams.

OK, I see what you mean. This is on the same page where he writes that
"if(expression) " can only be followed by a block. The grammar he's
defining here is not that of javascript, but of the subset he calls the
Good Parts. That's the whole point of the book - dividing the language
into good and bad (and, in the appendix, awful) parts. I think most
people who work with any language for a while instinctively do the same
thing in their minds, and Crockford wrote a book about it. As I said,
it's not a tutorial, but a collection of opinions.

I don't think he says in words that he doesn't want to nest blocks.
Perhaps he couldn't think of any way of discouraging people from doing

... { ... if (true) { ... } ... } ...

Off the top of my head I can't think of a single reason to use a block
unless it's necessary (except following if/else/for/while/etc, which is
a question of coding style) so I think that excluding them from the Good
Parts was the correct choice. "if (true) {...}" doesn't make any sense
at all.
For the record, I do disagree on quite a number of other suggestions and
opinions in the book, but that hardly made it worthless for me.
- Conrad

[David Mark]

On Oct 12, 2:41*pm, Peter Michaux <petermich...@g mail.comwrote:

On Oct 10, 8:44*am, David Mark <dmark.cins...@ gmail.comwrote:

On Oct 10, 11:38*am, MartinRineh...@ gmail.com wrote:

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

>http://www.martinrinehart.com/articl...-closures.html

It gets off to a dubious start:

"I had the best books (Flanagan, Resig, Crockford)"

Flanagan has been proven clueless

I think "clueless" is incorrect and inappropriate. He knows a lot as

His name has come up here a lot over the years. It seems to me that
most of it was bad. I certainly wouldn't recommend buying his books.
He's no Resig when it comes to cluelessness. I'll leave it at that.

[Peter Michaux]

On Oct 12, 7:15*pm, David Mark <dmark.cins...@ gmail.comwrote:

On Oct 12, 2:41*pm, Peter Michaux <petermich...@g mail.comwrote:

On Oct 10, 8:44*am, David Mark <dmark.cins...@ gmail.comwrote:

On Oct 10, 11:38*am, MartinRineh...@ gmail.com wrote:

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

http://www.martinrinehart.com/articl...-closures.html

It gets off to a dubious start:

"I had the best books (Flanagan, Resig, Crockford)"

Flanagan has been proven clueless

I think "clueless" is incorrect and inappropriate. He knows a lot as

His name has come up here a lot over the years. *It seems to me that
most of it was bad.

People seem to like to point out the mistakes because that is actually
useful. It would be boring and pointless to read about all the he
wrote that are correct.

I certainly wouldn't recommend buying his books.

That is a different story. I would recommend his book but would warn
that there are errors both small and large. I think a beginner is best
served by a paper book that covers the language and the DOM.
Flanagan's book fits that bill best of the options available. It isn't
so good to say to a beginner, "hey there are some documents on there
and there on the web. Try the terse specs and the Mozilla site and the
archives of c.l.js are good but there is a lot of pedantic arguing to
wade through. Just jump in the deep end with the sharks." Flangan's
book is a much more gentle introduction.

Peter

[sasuke]

On Oct 10, 9:07*pm, Lasse Reichstein Nielsen <lrn.unr...@gma il.com>
wrote:

>
[snip]

A closure is a piece of code together with a binding of values to the
free variables of that code.

A free variable is one that occur in the code, but is not declared
there.

So does it mean that even global variables in Javascript are `free
variables' given the fact that they can be used without being declared
or is it that the definition is a loose one?

Also, given the function:

---------------------------------->B--------------------------
function attachEvents() {
var divs = document.getEle mentsByTagName( "DIV");
if(!divs) return;
for(var i = 0, maxI = divs.length; i < maxI; ++i) {
var d = divs[i];
d.onclick = function() {
// some complicated processing with a lot of variables
alert("Hello from " + d.id);
}
}
}
window.onload = function() {
attachEvents();
// something complicated
attachEvents();
}
---------------------------------->B--------------------------

Will the second invocation of the function `attachEvents' make the
execution context of the first run along with the previously created
function objects eligible for garbage collection or do they need to be
explicitly grounded [set to null]?

/sasuke