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. |
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.2013/9/3 tim Rowledge <[hidden email]> 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. |
In reply to this post by timrowledge
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: > 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. > > > |
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. |
Free forum by Nabble | Edit this page |