On 05 Dec 2013, at 7:48 , Max Leske <maxleske@gmail.com> 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. 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.