I think they implement enough OO concepts to be considered objects in their own right. They're very simple, and only have one method, but they're still objects. They encapsulate behavior behind that method. They are also polymorphic, as long as they take the same parameters (curried versions can help there). I think it's fair to call them objects, and rather rigorious ones at that, though with limited functionality.

I don't think that we are going to come to agreement on whether closures are objects. Of course you can shoehorn your understanding of closures into an OO framework. But that isn't a useful view because it seriously misleads you about how to actually make effective use of them.

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