[squeak-dev] Faster FileStream experiments
nicolas.cellier.aka.nice at gmail.com
Fri Nov 27 11:57:28 UTC 2009
2009/11/27 Diego Gomez Deck <DiegoGomezDeck at consultar.com>:
>> Nicolas> The path to a cleaner/faster stream library is longer than just this
>> Nicolas> little step. Beside testing, we'd have to refactor the hierarchy,
>> Nicolas> insulate all instance variables, and delegate as much as possible as
>> Nicolas> Igor suggested. We'd better continue on the cleaning path and not
>> Nicolas> just add another FileStream subclass complexifying a bit more an
>> Nicolas> unecessarily complex library.
>> Michael Lucas-Smith gave a nice talk on Xtreams at the Portland Linux Users
>> Group. The most interesting thing out of this is the notion that #atEnd is
>> just plain wrong. For some streams, computing #atEnd is impossible. For most
>> streams, it's just expensive. Instead, Xtreams takes the approach that #do:
>> suffices for most people, and for those that can't, an exception when you read
>> past end-of-stream can provide the proper exit from your loop. Then, your
>> loop can concentrate on what happens most of the time, instead of what happens
> I think we need a common superclass for Streams and Collection named
> Iterable where #do: is abstract and #select:, #collect:, #reject:,
> #count:, #detect:, etc (and quiet a lot of the messages in enumerating
> category of Collection) are implemented based on #do:
> Of course Stream can refine the #select:/#reject methods to answer a
> FilteredStream that decorates the receiver and apply the filtering on
> the fly. In the same way #collect: can return a TransformedStream that
> decorates the receiver, etc.
> Just my 2 cents.
> -- Diego
Yes, this is gst approach, and it seems a good one.
More information about the Squeak-dev