[Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default
maxleske at gmail.com
Thu Dec 5 04:25:34 EST 2013
On 05.12.2013, at 10:12, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:
> On 05 Dec 2013, at 7:48 , Max Leske <maxleske at 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.
> 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… :)
> 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.
More information about the Pharo-dev