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:
>

Maybe I'm wrong but I think traits are a good (better) solution for that
kind of problem. #do can be a required method and you can implement
remaining methods with #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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091127/f1098c4d/attachment.htm