Well, that fix does not break any tests.  Anything asking for
#contents that only needs #upToEnd deserves to break.

I'll commit this to trunk soon.

On Tue, Sep 3, 2013 at 3:16 PM, tim Rowledge <tim at rowledge.org> wrote:
> This seems to be something that crops up every now and then and I'm never sure I've really worked it out fully. Typically I seem to recall arguments about what a WriteStream should return for contents.
>
> FileStream carefully sets its read position to 0, gets the contents (which is from read position to end) and resets the read position
> InflateStream does upToEnd
> PositionableStream does 1 to read limit
> RWBinaryOrTextStream (love those class names…) does 1 to max of read limit & position
> ReadWriteStream does similar, as does WriteStream
>
> Since MultiByteBinaryOrTextStream is a subclass of ReadWriteStream I'd say it ought to behave similarly when possible. Right now using upToEnd is the 'problem' so a quick test would be to just 'self position: 0' before the upToEnd. The converter fudging after the read will return the position to whatever it was at the beginning, so that is all covered.
>
> Then track down all senders and make sure they aren't going to be messed up by your change….
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Has a pulse, but that's about all.
>
>
>