so in that case I would be in favor to remove them because this does not help and just bloat the image.
On Jul 16, 2009, at 8:21 AM, Lukas Renggli wrote: >> select: selectBlock thenCollect: collectBlock >> >> | newCollection | >> newCollection := self species new. >> self do: [:each | (selectBlock value: each) ifTrue: >> [newCollection add: >> (collectBlock value: each)]]. >> ^newCollection > > That code would also break Dictionary and Array. > > I think the methods #select:thenCollect: and #collect:thenSelect: > should be removed: > > - This is a low level optimization that the compiler (or JIT) should > optimize, not the developer. > - 'a select: b thenCollect: c' is longer to write than '(a select: b) > collect: c'. Furthermore it is not that obvious what it does. I have > seen several people being confused about it. > - This is just #select:thenCollect:, what about > #reject:thenCollect:select:thenInjectInto:? What about all subclasses > that require a new implementation (Array, Dictionary, ...) of such > methods. > > If people really want to be able to combine enumerator methods for > higher efficiently the Collection hierarchy should be fixed. Having > external iterator objects like in C++ and Java is not that bad after > all: > > result := aCollection iterator > select: [ :e | ... ]; > collect: [ :e | ... ]; > contents > > The accessors #select:, #reject:, #collect: ... on the iterator object > would just iteratively create a new iteration block that is lazily > executed when the result is accessed with #contents, #size or #do:. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
