![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
tcepsaActually, at this point it has been somewhere between one year and two since I encountered the programming concept of "closures". When I first encountered closures it was in the context of Javascript, and someone had told me that I should be careful with the toolkit that I was using at the time (Dojo 0.42) because it apparently used them and they have a propensity for causing memory leaks. I did a little bit of exploring but was unable to come up with a satisfactory explanation of what they were or why they would have this effect. The result was that I had a sort of nebulous impression that a closure was something that happened--not something that was--when a newly created object ended up with a reference to one or more of the local variables back in the method that called it.
That was pretty much my understanding--and I knew it couldn't be right but at the same time I was keeping an eye on my memory usage and it didn't seem to be getting gobbled up too quickly, nor did it seem that it was never being released. So at the same time it wasn't really a pressing enough issue for me to pursue it terribly deeply. Then, last Autumn, I went to the No Fluff Just Stuff consortium and learned of a language called Groovy. One of the things that makes it so powerful is that it has fairly extensive support for these closure thingies. I got a slightly refined understanding of closures (at least Groovy closures) during the conference and figured that maybe they had decided to use the word (which I still thought was more of a verb) to refer to these somewhat magical functions that could be passed around like variables and have properties like objects and retained references to the local variables that were in scope when they were created.
And now today, about four months later, I was reading the appendix to this article and came across a parenthetical statement that finally tied everything together: "In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) [...]"
It's like there's this lightbulb in my brain that I screwed in back when I first heard the term, and it's been sort of glowing dimly off a trickle current this whole time, and when I read that finally it flared into brilliance! It's called a closure because, for all practical purposes, it's enclosed!! And therefore it can see all of their variables! And furthermore it can screw up garbage collection because it has a reference back to the enclosing object and garbage collection only happens on objects that aren't being referenced by anything that is, or is being referred to by, something on the stack! It doesn't actually screw up garbage collection--GC continues to do its job just the way it is supposed to--but it can trip you up, and that's what they were talking about when I first heard the term.
EUREKA!!! ^_^
(while my understanding may still be less than complete, it is a quantum leap better than it had been before reading that sentence ~grin~)
That was pretty much my understanding--and I knew it couldn't be right but at the same time I was keeping an eye on my memory usage and it didn't seem to be getting gobbled up too quickly, nor did it seem that it was never being released. So at the same time it wasn't really a pressing enough issue for me to pursue it terribly deeply. Then, last Autumn, I went to the No Fluff Just Stuff consortium and learned of a language called Groovy. One of the things that makes it so powerful is that it has fairly extensive support for these closure thingies. I got a slightly refined understanding of closures (at least Groovy closures) during the conference and figured that maybe they had decided to use the word (which I still thought was more of a verb) to refer to these somewhat magical functions that could be passed around like variables and have properties like objects and retained references to the local variables that were in scope when they were created.
And now today, about four months later, I was reading the appendix to this article and came across a parenthetical statement that finally tied everything together: "In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) [...]"
It's like there's this lightbulb in my brain that I screwed in back when I first heard the term, and it's been sort of glowing dimly off a trickle current this whole time, and when I read that finally it flared into brilliance! It's called a closure because, for all practical purposes, it's enclosed!! And therefore it can see all of their variables! And furthermore it can screw up garbage collection because it has a reference back to the enclosing object and garbage collection only happens on objects that aren't being referenced by anything that is, or is being referred to by, something on the stack! It doesn't actually screw up garbage collection--GC continues to do its job just the way it is supposed to--but it can trip you up, and that's what they were talking about when I first heard the term.
EUREKA!!! ^_^
(while my understanding may still be less than complete, it is a quantum leap better than it had been before reading that sentence ~grin~)
no subject
Date: 2008-02-20 01:53 am (UTC)no subject
Date: 2008-02-20 04:11 am (UTC)It was also amusing to realize that I already know a dialect of Lisp without realizing that I knew it--I studied Scheme briefly about two years ago when I wanted to do make the GIMP do some very specific things and realized that scripting would be the best way to get that kind of control... I've forgotten most of it now, but it seems like it would probably be worth looking into learning again, and in more detail. Can I poke at you with questions about it? (like which dialect would be a good place to start? Common Lisp?)
(~wry grin~ I'm also apparently picking up Perl, Python, and Groovy... why not go for four? And in ten years, when they all converge, I'll be able to create anything! ~giggle~)