Stream mixins?

[Janice Caron]

On 11/11/07, BCS <ao at pathlink.com> wrote:
> What you seem to want
> is to pass a chunk of data. For this you should use the lower level functions.

No, a stream of data. A property of hash functions is that you can
pass the data all in one chunk, or you can pass it in lots of little
chunks, but either way you'll get the same answer. If you can accept
the data a byte at a time, then it should be trivial to turn it into a
stream.

This is, in fact, the case, with Tango. I'm happy to agree they got that right.


> 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 may have been misunderstood. I have no problem with a /class/ doing
high level (or low level) stuff. Putting it all into a class makes
thing easier for the implementor, because all you have to do is derive
from the class.

My complaint was that these functions exist in an /interface/. This
means that implementers aren't being told exactly what they need to
implement, and functions which accept such interfaces won't know what
to expect.

If it's in an interface, we really need to nail down exactly what the
functions are supposed to do.



> 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.

Again, none of this is a problem for classes. The base class could, if
desired, implement writeBigEndian() and writeLittleEndian(), and then
they'd be available for all subclasses.

But the minute you put stuff like that into an interface, with no
handy class to derive from, you just make w-a-y too much work (and
potential for errors) for the implementor.



> You still can get all the benefits of nailing down the format with, as you
> pointed out, a mixin.

Yes. That's what I was asking for.

Although, even in that case, it would still be advisable to change the
docs for those interfaces from "this is implementation specific" to
"here is exactly what it must do".



> 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.

Exactly, yes. But the same argument works in general - not just for
hash functions. For /any/ kind of output-only stream, you should not
be expected to have hand-code your own printf()!