Modern Javascript is firmly on the side of magic. Why write a hundred-line set of meticulous loops when you can write a ten-line filter chain? Why invoke a factory object dozens of times when you can write a map function? And if you want your application's behavior to change from moment to moment, why use explicit states, or a Strategy pattern, or reference a global flag, when you can just swap out the functions themselves?

And why swap functions yourself? Let the functions do that for you. Wind them up. Let them run.

It has been obvious for a few years now that Flash has an ever-shrinking place in the future, but in the near term, Flash work is plentiful and development is ongoing. It seemed reasonable to start writing about programming techniques for the benefit of Flash developers who are still working with Actionscript in the real world, right now. Unfortunately, Adobe recently drove two more nails into Flash's coffin by announcing the end of Flex and the mobile Flash player.

It seems wise to program—and write—for the future. It's ironic that just as I was writing a blog series about how to use a port of Jeremy Ashkenas's underscore.js library, his CoffeeScript language overtook Actionscript as the 15th most used language on Github. A sign of the times, and a signal that although I should write about the same topics, I should focus on HTML5 instead of Flash. As planned, the next post will be about functions that transform functions; but expect the examples to be in Javascript.

A closure stores information. It can have access to a single parameter given to it at runtime; or to an internal data structure it can use to make decisions; or even to large chunks of your program's state, letting you pass behavior without needing to pass information. In this post, I'll show you how to use closures to work with arrays: in a few lines of code, you can grind a nested data structure down to just a handful of targeted values. With a few more, you can transform them into anything you need. And with a pinch of closure fairy dust, you can make those filters and transforms magical, building powerful and intelligent functionality up from a few lines of initializer code. The results will fascinate and horrify. But mostly fascinate.

In Anonymous Functions in AS3, we looked at how anonymous functions can simplify code structure, but we skirted around their most powerful capability. An anonymous function can hold additional data, beyond what it gets from its arguments, and it can use that data in its work.

By holding extra data, an anonymous function can be custom-designed, on the fly, to perform a specific duty; it can apply special logic it normally couldn't have access to; it can access application state; it can even "transform" other functions, changing their behavior, without needing access to their internals, through a sneaky substitution known as "wrapping"; but before we can put closures to work, we need to understand what makes them tick.

In Actionscript, functions are objects which can be stored in variables and passed as arguments, just like any other value. Since functions are treated just like any other object—like "first-class citizens," if you will—AS3 is said to have "first-class functions." This lets us do stuff that would be cumbersome in other languages, but it also throws a whole new set of potholes in our path. This post shows how to use first-class functions for state-based event handling, user input interpretation, and array filtering, but I'll begin with something you've seen a million times before: the lowly event listener.