[squeak-dev] surprising behavior from MultiByteBinaryOrTextStream>>#contents

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Sep 3 20:20:54 UTC 2013


I just hate those read/write streams, there are unecessarily complex,
behaving quite randomly as underlined by tim, and 99% of time unecessary at
all.
Here you just need a write stream, clearly.
Xtreams has no read/write stream.


2013/9/3 tim Rowledge <tim at rowledge.org>

> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130903/f1f3b825/attachment.htm


More information about the Squeak-dev mailing list