Now it is true that implementing a traversal method on the collection class itself is more powerful in most situations (e.g. Smalltalk: #do) but where I see a problem is e.g. Common Lisp's "mapcar" function. It can map over an arbitrary number of collections.

So my question is; is the iterator pattern bad for implementing this scenario? I looked at the SBCL source code and they seem to be doing exactly this (granted they use closures for iterating, but it doesn't look like the generator strategy to me). I see in [3] they make the case for using generators instead of the iterator pattern but this doesn't look very easy to use on an arbitrary number of collections (in fact I'd like to see an implementation of it, as it's not immediately clear to me how it would be done). Further, I don't see what is being bought here. The function passed to map isn't protected from the collection being mutated by another thread anymore than an iterator would be.

I would certainly agree that Iterator is an inferior approach in most scenarios but for mapcar-like scenarios? What do you think?

[1] http://blog.plover.com/prog/design-patterns.html

[2] He mentioned Perl as not needing this pattern and showed a foreach example. But the fact of the matter is that foreach in Perl can only iterate the built in list type. It wouldn't work on custom made collections.

[3] http://home.pipeline.com/~hbaker1/Iterator.html