On Jul 16, 2009, at 2:16 PM, Paolo Bonzini wrote:
On 07/16/2009 11:38 AM, Stéphane Ducasse wrote:
Paolo
why Iterable as a superclass of stream and collection? Why not a trait? Then I'm wondering why this would be faster.
Maybe for just "(a select: ...) collect: b" it would not be faster.
However, the important thing is to provide:
1) a new abstraction. Providing more polymorphism between Collections and Streams can only do good, especially when the semantics are 100% identical as for #detect: or #fold: (based on #do:). In GNU Smalltalk I did a bit more by providing also #readStream and #nextPutAllOn:, but that's not necessary so I kept my pharo proposal minimal.
2) a new bag of tools. Lazy filtering has been proposed in many different ways, so it *is* useful. Adding Iterable is in my opinion the best way to provide this tool in a way that fits the simplicity of the standard Smalltalk class library (this is a way to say that #doesNotUnderstand: tricks have their place, but other ways should be explored as well).
sure but for me my point was collect:thenSelect: looks badly implemented. Now you can that composed Stream. Damien has that in Nile since two years too.
Paolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project