To avoid such kind of situations I would implement all the traversal methods as
a) Traits or
b) Class side methods of DeepTraversal (you choose the name) to which
you'll have to pass the collection and the block.

E.g. DeepTraversal deep: aCollection do: aBlock
DeepTraversal flatten: aCollection thenDo: aBlock

I, personally, don't like adding methods to Object unless it's
unavoidable(*). And in those cases I choose to prefix them with
something that is separate from the semantic, usually the
package/framework prefix.

Regards,

(*)I did that for years and in the long term it hits you back.
Esteban A. Maringolo


2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:

> Hi.
>
> I was reading with interest the blog post on Traversal-enabled objects (
> http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when
> I noticed the method #deepCollect: referenced. �Interestingly, I have a
> method called #deepCollect: that is use (wtih related methods like #deepDo:
> and #deepSelect:). �I suspect these uses may be compatible, with the
> traveral versions being more generic.
>
> My set of #deep methods allow arbitrary flattening of collections. �The
> #flatCollect: suite in Pharo today flattens objects 1 level; the
> #deepCollect: flattens the collections as many levels deep as they are
> nested. �I found this to be a really useful ability when I work with
> PetitParser parsings, which tend give back massively nested Arrays by
> default.
>
> If you are interested, it is published at:
> http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
>
> -cbc