Re: Closures versus objects

Callbacks.

I want to arrange for something to happen on some trigger, so I give the 
triggering thing a closure (or many closures) to execute. The thing that fires 
off the closure doesn't need to know anything about what will be done.

You could do this with objects by storing objects to send a message to (e.g., 
#fired), but then you have to arrange for all possible objects to support the 
#fired message. (And if you're working with a large system, you'll have 
namespace issues among the messages, and base-class issues among the possible 
objects that you don't own and can't add new messages to.)

You could do this with a generic messaging system, but then you're managing a 
whole publish/subscribe mechanism that has analogous problems.

Thus closures are not just really flexible objects, they're really flexible 
messages, too.

Mike Newhall wrote:
> ... 
> As a perhaps separate thought, what are closures useful for?  That is, for
> those of you who have had the luxury of programming in a language with
> closures for many years, what uses have you found that might not be obvious
> to programmers that have grown up closure-deprived?  How would you "sell"
> closures to programmers steeped in old habits?  What's your "Top 10" (or Top
> 3) list of the cases where closures do the job better or make life easier?
> 
> 

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[email protected]
jabber:[email protected]
voice:+1-608-262-3724