[ANSI-Smalltalk] #contents on <collectionStream> (was: #contents on WriteStream)

[Richard O'Keefe]

On 21 Oct 2008, at 6:49 pm, Bruce Badger wrote:

> 2008/10/21 Richard O'Keefe <ok at cs.otago.ac.nz>:
>> On 21 Oct 2008, at 6:44 am, Bruce Badger wrote:
>>> Or perhaps there needs to be a family of stream classes each with
>>> obvious behaviour.  It would be nice to have as much consistency as
>>> possible, but things like >>contents will inevitably be different
>>> depending on the underlying 'collection'
>
>> The *implementation* will be different.
>> It is far from clear that the *semantics* should be different.
>> It certainly isn't *inevitable* that the semantics differ;
>> the standard says it shouldn't, and in my library it doesn't.
>
> So, in your library, if I send >>contents to a socket stream what do I
> get?  If I >>reset a socket stream what is the position of the socket?

I really sweated over that one.
However, there is one design rule that I have tried very
hard to follow:
	"keep #respondsTo: honest".
If an operation never makes sense for an object,
it should not be in the interface.

My original intention with sockets (actually, I was worrying
more about pipes, got to crawl before you can run) was to
take advantage of what I had done for file streams.
I finally gave up.  So I have

     *InputStream "no #peek or #peekFor:"
       *PeekableInputStream "#peek and #peekFor: go here"
          *ChannelInputStream "goes through a UNIX fd"
	    ChannelByteInputStream
	    ChannelLatin1InputStream
	    ChannelUTF8InputStream
	   *FileInputStream  "the fd can do lseek()"
	      FileByteInputStream
               FileLatin1InputStream
               FileUTF8InputStream

with a similar hierarchy for output streams.  (The asterisk
marks abstract classes.)  I'd really like some kind of
multiple inheritance, perhaps like Traits, and there's another
candidate for the revised standard; the duplication of
Channel*InputStream and File*InputStream annoys me, but not
half as much as 'self shouldNotImplement'.

By the way, it's this kind of thing which makes the standard's
provision of a "factory" for making file streams rather than a
specific set of classes so right, and so worth emulating in
the revision.  Other Smalltalk implementors have made very
different decisions.


So the answer is
(1) if you send #contents to a socket stream you get a DNU
(2) if you sent #reset to a socket stream you get a DNU