Daniel, I don't have a definitive answer for you. I took an interest to browse what was built into Pharo (using Tools > Finder > Classes and searching for "stream" and also for "read") and looking at the hierarchy of several results it seems there is a mix. I suppose the fall back position is "do the simplest thing that works."
On Sun, Jan 18, 2015 at 1:11 PM, Daniel Lyons <fus...@storytotell.org> wrote: > This is an OO design question. > > For my task, I have some objects and a particular file format that encodes > them. I want to be able to read the file and create those objects. The > Stream API seems like the right way to do this, but I'm not sure how to > encapsulate my code. I see these options: > > • Create a new class (subclass of Object) that implements #next to return > the next object in some underlying stream. > > Pro: very simple, one place with all the code. Con: what about the rest of > the Stream and/or Collection APIs? Is it wise to delegate everything else > to the underlying stream with #doesNotUnderstand:? > ImageReadWriter seems an example of this - but I don't think it delegates #doesNotUnderstand: - it looks like it implements the full protocol in the "stream access" protocol. It has an instance variable /stream/ that it forwards t > > • Create a new class, subclass of Stream, that implements #next like the > above. > > Pro: still pretty simple, not sure what is needed to implement the API > completely (I did add a method #atEnd). Con: not sure if more methods are > missing; unclear about initialization (overrode class>>#on: to call > #basicNew). This seems close to the right approach but I'm unsure. > > • Create a method #nextFoo on the existing Stream class. > JPEGReadStream and TxCharacterStream seem examples of this. cheers -ben > Pro: very simple—no new class. Con: nextFoo doesn't integrate well with > the rest of the API (#do: for instance), not sure this is clean or wise. > > • Ignore the Stream classes altogether. > > Pro: No chance of misundestanding. :) Con: everything else. > > Advice? > > Thanks for your time, > > — > Daniel Lyons > > > > >
