Thanks for the input. The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. I’ve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if there’s some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams.
Cheers, Max On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote: > Here would be the Xtream way IMHO: > 1) At the end, the file should be handled as binary. > 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, > able to switch encoding > 3) The implementation would be to wrap either directly over the binary > stream, or indirectly over an encoded stream which wraps other the binary > stream. > 4) For write, the facade should just ensure that buffers (if any) are > properly flushed, and then just delegate to specialized wrapped streams. > 5) For read, it might be a bit more involved if some buffer were used in > intermediate wrappers, because they should push back the excess bytes read > and restore the state of lower level binary stream... > In all case, all should happen thru delegation and the facade should be > rather dumb. > > > 2013/12/4 Sven Van Caekenberghe <s...@stfx.eu> > > On 04 Dec 2013, at 13:14, Max Leske <maxle...@gmail.com> wrote: > > > Let me see what I can come up with. > > To be somewhat compatible with existing streams, your memory stream should > have the concept of ‘i am binary or textual’ and be able to switch in-place > between these two states (#binary, #ascii). Depending on its state it should > then return bytes or characters (or collections thereof). Have a look at > ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: > > To be 100% correct, encoding should be selectable. But maybe a default to > utf-8 would be enough. You could have a look at ZnCharacter[Read|Write]Stream > for inspiration. > > My 2c. > > > On 03.12.2013, at 19:36, Damien Cassou <damien.cas...@gmail.com> wrote: > > > >> Thanks Max for the report. Do you have an idea on how we could solve the > >> problem ? The previous behaviour was not acceptable either because the > >> streams that came out of a memory filesystem were the only ones with > >> binary content > >> > >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxle...@gmail.com> wrote: > >> Damien, Marcus > >> > >> this change breaks a lot of things in FileSystem-Git. I don’t disagree > >> with the idea that reading characters should be default (one could argue > >> about it…) but your change makes it IMPOSSIBLE to read bytes because > >> unprintable characters are discarded! So if my ByteArray is a NULL > >> terminated string, for instance, I can not check for the NULL termination > >> anymore. > >> > >> Cheers, > >> Max > > > > >
