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. 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
