I use them a lot... just because "select:thenCollect:" looks clearer to me than "(select:)collect:", and I can indent the code in a more fashion way to me. Of course, if you choose remove it, I can change my code without any problem (it is not so hard, after all :) ), but I just wanted to point that optimization is not always the reason because a protocol can be added... some times, is gramatics too. Cheers, Esteban On 2009-07-16 07:02:56 -0300, Andres Valloud <avalloud@smalltalk.comcastbiz.net> said:
I'd favor removing such methods. The allocation optimization can be
implemented better whenever it's needed, and IME it doesn't happen that
often.
Stéphane Ducasse wrote:
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 .