Re: Closures versus objects

>
>
> Closures are good at capturing bindings ("fields") without the need
> to declare what you want to capture upfront. If you change your mind
> about what to capture, there is only a single place that you have to
> change. It's so easy to do this that you typically don't even realize
> that your "objects" have changed their "layouts". With objects, when
> you want to create new ones that should get more fields, you have to
> change the corresponding class definition to do so as well (at least
> in the mainstream OOP languages).
>
>
I've long considered closures to be "lightweight" objects, and this comment
points out a fundamental reason for this.  In my view, the "killer app" for
closures is in callback functions, whether used as event handlers or as
inputs to higher order functions like map.

Objects combine the functionality of closures with a module system.  This is
especially true in languages like C++ that don't have a separate module
system, and objects are often used to fill the gap.  The other extreme is
found in Perl, whose object system is implemented in terms of packages.
Sometimes, the addition of the namespace control objects provide is helpful
for structuring code; other times, it isn't needed and just gets in the way.


- Spencer