[squeak-dev] Faster FileStream experiments

Nicolas Cellier 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
>> rarely.
>
> 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.
>
> Cheers,
>
> -- Diego
>
>

Yes, this is gst approach, and it seems a good one.

>
>



More information about the Squeak-dev mailing list