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...@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
