Closures versus objects

	One topic that seems to have been a perennial or at least occasional topic of discussion is the relationship between closures and objects and their substitutability.  Chistian Queinnec mentions this dichotomy / competition in Lisp In Small Pieces.  I have not yet had the experience of witnessing such a fight so perhaps it would be educational to instigate one here. :-)  Some questions for your consideration:

	Closures clearly can be used to make object-like things, and objects can be used to make closure-like things.  Is one demonstrably "better" than the other, in a theoretic or practical sense, or both?

	Concretely, from a language-design point of view, is it redundant to include both features?  (assuming a "general purpose" language is the goal, for some value of general)  Or is it merely theoretically redundant, but in practice it is useful to have both?

	If the main use of closures is to associate data with code, and the mechanism of capturing the lexical context is merely a means to an end, then "closure-like" objects are possible even in languages with no concept of capturing the stack.

	Nevertheless closures would seem to have the edge when you need something that behaves exactly like a function.  But some OO languages allow you to invoke an object with function-like syntax.  In C++, this is merely syntactic sugar, but there's no reason a language couldn't be designed to allow objects to be invoked in a way semantically identical to functions (ignoring CLOS generics for the moment, surely some OO languages already do this; Python?  JavaScript?), invoking some default method.  This equivalence can break down however when, for example, an external entity like the OS requires a callback function, and the semantics of invoking the callback are outside the playpen where this equivalence is implemented, so that only true closures would work in the context.  But this could be said of many language features.  It's of particular concern in the C++ world where C calling conventions for OS callbacks are the norm and object invocation is not an option.  (For that matter, any language with closures attempting to use a C callback has to solve this problem.)

	Objects would seem to have the edge when you want the relationship between functions that share state to be explicit both syntactically and in the language.  This may be necessary to enforce inheritance & access rules and so on.  Also it would seem that if everyone rolled their own OO system with closures they would inevitably be incompatible, although a standard library might obviate that.

	Or could closures and objects be unified into a single datum, such that foo() invokes "the" closure function but foo.method() invokes other functions sharing the same state?  (This is the same semantics suggested above but with the extension that lexical closures do exist in the language, and any time a closure is captured, it generates an object indistinguishable from those produced by constructors.)

	As a perhaps separate thought, what are closures useful for?  That is, for those of you who have had the luxury of programming in a language with closures for many years, what uses have you found that might not be obvious to programmers that have grown up closure-deprived?  How would you "sell" closures to programmers steeped in old habits?  What's your "Top 10" (or Top 3) list of the cases where closures do the job better or make life easier?