[ANSI-Smalltalk] #contents on <collectionStream>

[Paolo Bonzini]

> As far as I know, current practice is (mostly):
> 
>     the single selector
>         #contents
>     which for readable streams answers 
>         self upTo: readLimit
>     and for writeable streams answers
>         self upTo: position
> 
> I have, up to now, resolved said ambiguity
> in favor of the readable property, i.e.
> 
>     ReadWriteStream #contents answers
>         self upTo: readLimit.

Agreed.

> I've also added the selector #currentContents,
> which provides the opposite resolution:
> 
>     for WriteStream and ReadWriteStream answering
>         self upTo: position
>     but otherwise (i.e. for read-only streams) answering
>         self upTo: readLimit

Shouldn't this be "position for ReadStream and ReadWriteStream, and
readLimit for WriteStreams"?  It seems to me that the two are
substantially different cases and don't fit very well in the
do-what-I-mean nature of #contents.

For reading up to the end of ReadStream, discarding past values, there
is #upToEnd at least in VA and GNU Smalltalk (do not have the others at
hand).

For reading past and future values in WriteStream you could do "x
setToEnd; contents" but I never found a usage for it.  The current
behavior is sometimes useful to do something like

   x do: [ :each | s print: each; nextPut: $, ].
   s skip: -1.
   ^s contents

... though these days #do:separatedBy: is much clearer and works with
all streams.

Defining #contents to do this is relatively hard, however, using the
paradigm of the standard.  It would entail, in particular, adding a new
protocol  <sequencedGettableStream> deriving from <gettableStream> and
<sequencedStream>; all the definitions of #contents in the standard
would be removed and replaced as follows:

- in <gettableStream> #contents is added and provides future values only

- in <sequencedGettableStream> its meaning is changed to provide past
and future values

- <ReadStream> and <readFileStream> should now derive from
<sequencedGettableStream>

- in <WriteStream> #contents is added and provides past values only

- in <ReadWriteStream> it is defined explicitly to have the same meaning
as in <ReadStream>, rather than as in <WriteStream>

This fixes also what could be considered an erratum, i.e. that #contents
is available in <writeFileStream>.

But still, ouch...

Paolo