surprising behavior from MultiByteBinaryOrTextStream>>#contents

When I

     (WriteStream on: String new) nextPutAll: 'hello'; contents

I get the expected result, 'hello'.  However, when I use a
MultiByteBinaryOrTextStream:

     (MultiByteBinaryOrTextStream on: String new) nextPutAll: 'hello'; contents

Empty string.

It seems the latter only provides contents upToEnd from its current
position, so I have to:

     (MultiByteBinaryOrTextStream on: String new) nextPutAll: 'hello';
position: 0; contents

to get what I expect.

#contents should always provide the full contents of the stream, shouldn't it?

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has a pulse, but that's about all.

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 <[hidden email]> wrote:

At Tue, 3 Sep 2013 16:49:27 -0500,
Chris Muller wrote:
>
> Well, that fix does not break any tests.  Anything asking for
> #contents that only needs #upToEnd deserves to break.

Etoys loading and saving may be relying on the (inconsistent) bahavior, though.  And there is #with:

(RWBinaryOrTextStream with: 'abc') contents => 'abc'.
(MultiByteBinaryOrTextStream with: 'hello') reset contents => 'abc'.

-- Yoshiki

>> Well, that fix does not break any tests.  Anything asking for
>> #contents that only needs #upToEnd deserves to break.
>
> Etoys loading and saving may be relying on the (inconsistent) bahavior, though.

It looks like there are only 36 senders of #contents in the Etoys
package.  So it shouldn't be too tough to patch Etoys.

Etoys is a very important application.  At the same time, every other
stream-type behaves one way w.r.t. #contents.  Should we tolerate this
inconsistency in the general-purpose library to accomodate one
application or should the application be changed?

Is Etoys running on the trunk image?

> And there is #with:
>
> (RWBinaryOrTextStream with: 'abc') contents => 'abc'.
> (MultiByteBinaryOrTextStream with: 'hello') reset contents => 'abc'.

As well as:

  priorPosition := myMultiByteBinaryOrTextStream position.
  myContents := (MultiByteBinaryOrTextStream with: 'hello') upToEnd.
  myMultiByteBinaryOrTextStream position: priorPosition

I only used #on: for the example.  I think #contents should
consistently answer the full contents, regardless of which stream-type
or how it is created.