Stream mixins?

[BCS]

Reply to Janice,

> On 11/11/07, BCS <ao at pathlink.com> wrote:
> 
>> What would you then do for an object that has no write abilities, or
>> no read abilities? To be a bit silly, what good is a InputStrem
>> without an OutputStream somewhere?
>> 
> There are plenty of examples of those!
> 
> /dev/random is an input stream with no output stream /dev/null is an
> output stream with no input stream
> 
> What I was actually planning to do was implement a hash function (e.g.
> SHA-256) as an output stream. You write your bytes to the stream, then
> call a function to get the hash of those bytes. By definition this
> would /have/ to be an output-only stream. That's the whole POINT of a
> hash function - it's /one way/!
> 
> But I don't see why, in order to do that, I should have to implement:
> 
> abstract void write(char[] s);
> abstract void write(const(wchar)[] s);
> Writes a string, together with its length.
> 
> The format is implementation-specific and should
> only be used in conjunction with read.
> Throw WriteException on error.
> If the format is implementation specific, then does that mean that I,
> as the creator of HashOutputStream, get to define the implementation?
> 

No, in your case the write() functions are useless. What you seem to want 
is to pass a chunk of data. For this you should use the lower level functions.

However, you may have a point in that the write functions may cause issues 
for some cases. Maybe there should be a WriteStreamLL that just has the non 
implementation specific stuff. and then have WriteStream extend it with the 
high level stuff.

I think it all derives from a design choice of "don't say you will do more 
than you have to". As an example, if the format was specified, what big-vs.-little 
endian? Do you pick one and let the other side suffer the overhead? As soon 
as you start nailing things down, where do you stop? The only logical choices 
I see are no spec and full spec. At the base level, full spec doesn't work 
to well.

You still can get all the benefits of nailing down the format with, as you 
pointed out, a mixin. You can even have several (big, endian, little endian, 
pick-one-at-write-time-endian) I think the point in the end is that if you 
need to be consistent about how you implement the stuff. If you ave a write 
only stream that never returns the stuff then impalement it however you want(*). 
If you have a reader and a writer, make sure they match and expect the user 
to use them in pairs.

* come to think of it. as long as you don't need to match your hash with 
someone else using different code then the formatting is irrelevant.