mthom wrote:
Shouldn't CLOS be used only if you have a real need for features you can't easily get with closures, like multiple inheritance and access to the internal state? It seems like so much unnecessary baggage otherwise.
I think it's mostly a matter of taste and preference, though I think CLOS can help with maintainability as systems grow larger and more complex.
Personally, I find it very useful for organising code and for passing bundles of state around with a minimum of programmer overhead; it also allows me to use pre-build generic machinery to quickly build up an API. It's possible that said machinery can become a performance bottleneck, but I don't operate at the scale of, say, ITA. If it _does_ become a performance limitation, remember that a call to a generic function looks like a call to any other kind of function, so you can seamlessly replace the OO stuff with closures (or whatever else) where your profiling shows that it's slowing you down. I'm also a devotee of the school of first making it work, then making it work correctly, then making it faster when and where speed actually emerges as a problem.
This article does a pretty good job of illustrating the mindshift that comes from thinking in terms of defgeneric first and worrying about actual objects later.
I'll probably get shot down for this, but I see an analogy with RDBMSes: sure, you can roll your own purpose-designed and perfectly performance-optimised system that's tailored for the specific problem at hand, but you also get the maintenance burden and learning-curve that goes with it, which is multiplied if/when other people get involved. Alternatively, you can use a pre-built generic system that can be molded to a very close approximation in much less time, and that many other people are already familiar with. It _could_ become a performance bottleneck, but a)it probably won't in practice, and b)if it does become a bottleneck, you can re-engineer the solution then. In the meantime, it lets you get on with the bits of your application that _don't_ already have a general solution - it speeds you up more than it slows you down.