Hi Daniel, I have disclaimers as the 2 previous responses, this is my feeling about the matter. :-) I would prefer to think purely in terms of the API that you want to use when reading the file, and have that clear and explicit. So do NOT subclass Stream nor do a class extension with #nextFoo. I would think in terms of the Stream API when doing that, and reuse as many message names as possible, because it is a fairly âstandardâ API. So: option 1, without the use of doesNotUnderstand.
On Jan 18, 2015, at 06:11, Daniel Lyons <fusion@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:?
⢠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.
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
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile