in reply to Why are closures cool, continued?

If you come from OO land, a good model of a closure is an arbitrary object with one method and no class.

At this moment you may wonder why not just use an object, then you aren't just limited to one method, and it is not like a class is a lot of overhead.

The answer is that someone can turn around and say, "Oh, I need a new kind of closure here" and inline it very easily within a function. (Frequently you parametrize different kinds of functions.) Creating a class is (relatively) a lot more infrastructure and verbiage.

The key words for most of the basic uses are "callback" and "handler". The callback idea is that you have people pass you some anonymous functions into your function, and then you call them at appropriate moments (sort of what you use method hooks for in OO design but you don't need to set up a class, an object, etc). The handler idea is that you set up various functions that will handle various specific cases, and when you encounter the cases you just call the handler and let it take care of things.

(It is not uncommon for what you think of as callbacks you pass into a function be handlers inside of it.)

A specific example to look at is ReleaseAction which very clearly shows how, once you have a little infrastructure code, you can do something you would normally do with a class without writing a class each time.

  • Comment on Re (tilly) 1: Why are closures cool, continued?