If I was going to put this as a linguistic metaphor, I'd say that objects make good nouns and closures make good verbs. You think about them completely differently, and you evolve designs with them differently as well. With objects you think about pieces that need to communicate with each other. With closures you evolve behaviours.

But that is rather vague. Read Why I like functional programming, Re (tilly) 1 (perl): What Happened...(perils of porting from c) and Re (tilly) 1: 5x5 Puzzle to get an idea of how I use closures in practice. If you don't get a sense from that code that manipulating closures "feels different" than OO design, then I really don't have any idea how to communicate the mindset shift involved.

I don't think that we are going to come to agreement on whether closures are objects.

No, probably not.

I don't think I really made this point very well above (which is my fault), but it's not that I put an absolute stamp on closures as objects. Rather, I think they can be used as a limited form of object, but they're not limited to OO, either.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

...it's not that I put an absolute stamp on closures as objects. Rather, I think they can be used as a limited form of object, but they're not limited to OO, either.

Imagining this as a Venn diagram, what then, I wonder, would be an appropriate name for the field of endeavor and design that exists in the intersection?

(I need to know so I can complete my OO model of OO-ish concepts...;)

Matt