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). Paolo _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
