It seems I've asked this question before:

   http://forum.world.st/surprising-behavior-from-MultiByteBinaryOrTextStream-gt-gt-contents-td4706322.htmlI

This made me remember some of the really great points and discussion
about the Stream design you've made in the past.  This, for example:

   http://forum.world.st/In-memory-FileSystem-write-streams-not-being-polymorphic-td4721006i20.html

Good to re-read that thread from time to time..


On Tue, May 1, 2018 at 5:16 PM, Chris Muller <asqueaker at gmail.com> wrote:
> C'mon, it has 9 tiny, concise methods, (15 including extensions from
> EToys and Compression) and so only Tim is allowed to characterize that
> as an "awful mess".  :)   No seriously, being the superclass for
> FileStream, it handles all of Squeak's file contents processing and works well.
>
> I guess Chris' explanation is a reasonable explanation for such glaring
> inconsistencies in behavior between superclass and subclass, so I
> ended up adding my own #content method which does what I want...
>
>
>
> On Tue, May 1, 2018 at 3:21 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> IMO ReadWriteStream is an awfull mess and should better not be used at all.
>>
>> 2018-05-01 22:00 GMT+02:00 Chris Muller <ma.chris.m at gmail.com>:
>>>
>>> Does anyone know why ReadWriteStream overrides #contents from WriteStream?
>>>
>>> WriteStream behaves as I would expect
>>>
>>>    |stream| stream := WriteStream on: String new.
>>>    stream nextPutAll: 'chris'; reset; nextPutAll: 'C'; contents     "--->
>>> 'C'   as expected"
>>>
>>> but ReadWriteStream doesn't...
>>>
>>>    |stream| stream := ReadWriteStream on: String new.
>>>    stream nextPutAll: 'chris'; reset; nextPutAll: 'C'; contents     "--->
>>> 'Chris'   unexpected!"
>>>
>>> I want to reuse a ReadWriteStream, so I want #contents to honor the end
>>> position.  What's going on here?
>>>
>>>
>>>
>>
>>
>>
>>