Stream mixins?

Janice Caron caron800 at googlemail.com
Sun Nov 11 09:46:45 PST 2007


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?

If so, how does a function like

    wstring f(InputStream is)
    {
        wstring s = is.readStringW();
        /* do something with s */
       return s;
    }

know what to expect?

Of course, the silly thing is that it's /easy/ for me to make a Stream
(as opposed to an OutputSteam). That's because Stream is a class, not
an interface. All I have to do is subclass Stream and override the
three abstract functions - job done! And if I make readBlock() through
a ReadException, and seek() throw a SeekException, then I do actually
/have/ what I want. That, basically, is problem solved.

Except ... it seems overkill because I don't need the read half. And
it makes me question the purpose of the OutputStream interface. Why
have it, if it so damned hard to use?



More information about the Digitalmars-d mailing list