While closures may look like a poor man's object, I
think the reverse is closer to the case.
Using only closures you can build an OO system, with what
looks like an OO syntax. I believe that Smalltalk's OO
system works like this. Definitely Lisp's CLOS does.
By making classes multiply like rabbits, you can
mechanically translate code involving closures into
code involving objects. But I am having trouble seeing
how you could make those closures integrate into an
OO language and look like they do in a functional
language. (Perhaps my imagination is not very good
though.)
Anyways what I find that closures do which OO does not
do so well is allow you to "inline" logic that in OO
programming would involve having to create classes and
methods just to do a small thing, privately, within a
function.
For instance take the DESTROY method. Perl
offers a way to use it in an OO context. If I want to
set up some sort of finalizing action on something, I
can always create a class, with a constructor and a
DESTROY method. Each different kind of action requires
a whole class. Ick.
However if you look at my ReleaseAction, it allows
you to do the same thing, with the action defined by a
closure. Now you can, within a small function, define any
useful DESTROY behaviour that you need, without having
to create a class for it. That allows you to put the
definition of the behaviour where it is most maintainable,
right where you need it. What you are doing isn't
fundamentally different, but you think about it more
compactly.
Let me step back, and explain that differently, since in
trying to say it I think I figured out a better way to
understand it.
Conceptually an object is the concept of a thing with
multiple customized behaviours, and with a defined
structure for building a system with lots of objects,
some of which share some of the same (or similar)
behaviours.
Conceptually a closure is the concept of a thing with
a customized behaviour.
It turns out that closures are general enough to allow
you to build arbitrary objects. They may not look like
they can do that, but they can.
However if what you need is a customized behaviour,
objects have a ton of baggage that you cannot shed. This
forces you to structure your code in a less natural
manner for the ideas expressed, and that overhead limits
how you tend to think about problems, forces unnecessary
duplication of code, etc, etc. As a result there are
solutions that are quite natural using closures which
people do not naturally build without them. (And if they
tried to build those solutions without closures, the
result would be an order of magnitude less efficient, but
I digress.)
UPDATE
In reply to hding, CLOS may not need to be implemented
with closures, but it is possible to do so. Also note that I tend to be somewhat sloppy in my wording. When I start throwing around anonymous functions, I tend to call them closures even though the functions I am passed might not really be closures.