Reading PG's criticism about OOP, he mentions that if he ever really needed objects, he'd use an array of closures instead. When I read this I knew little about what closures were, so intrigued I read up I them.<p>Now I can't figure out how they're different, except how a language might implement them.<p>So what is the conceptual and practical difference between the two?
An object has state, so imagine you have a skeleton and every time you change a property you are taking off an old bone and putting on a new bone. Eventually you might have 3 femurs, a couple of skulls, and five knees because of how objects are implemented (and how hard it is to keep straight).<p>A closure is like if you needed a forearm, you created one on-the-fly for the specific instance, and it exists as long as it's needed. You would never have the issue of having excess multiples of arms or legs because closures, although maintaining an internal state, only exist as long as they are invoked.<p>It's a simple example, but maybe that helps clear it up. Perhaps some people can help extend the metaphor if it proves useful.
@irixusr I'd recommend this page from C2:<p><a href="http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent" rel="nofollow">http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent</a><p>It may also help to contemplate the techniques used to get "private variables" in vanilla Javascript.
In theory they are the same thing, in practice they are not.<p>If you treat closures like objects, they are tedious, and missing lots of nice conveniences that OO languages provide for their objects.<p>If you treat Objects like closures then they are heavy weight, have too much formality, and have annoying limitations to work around.
The fundamental difference is this: a closure has a single operation; when you invoke it, it does that one thing. An object, in contrast, normally has many operations, so to invoke one of them, you have to supply its name.<p>That's not a big difference, but it is a difference.