2009/11/27 Diego Gomez Deck DiegoGomezDeck@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