On 05.12.2013, at 10:12, Henrik Johansen <[email protected]> wrote:
> > On 05 Dec 2013, at 7:48 , Max Leske <[email protected]> wrote: > >> 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 > > In my experience, the legacy solution for swapping binary/ascii writing to > in-memory collections is using a (MultiByte)BinaryOrTextStream instead of a > standard ReadWriteStream. You’re right. I had thought about simply using RWBinaryOrTextStream instead of ReadStream in MemoryFileSystem but that felt like committing a crime… :) > > Cheers, > Henry > > P.S. In fact, that class is pretty much the ultimate example of why the > XTreams approach is superior. > It *looks* like it’s interchangeable with (MultiByte)FileStream, but the > implementations are completely independent, and thus a subtle set of > differences are bound to exist. (and do, but I can’t remember exactly which > atm) > Maintaining and bug fixing either is a nightmare, and introducing further > divergence bugs in the long run is pretty much inevitable. > > Much better to composite singly implemented, single purpose wrappers streams > on top of dumb terminals for each destination type to achieve desired input > -> output transformations. > >
