On 10/15/10 14:54 CDT, Kagamin wrote:
Denis Koroskin Wrote:
I think, it's better to inherit Stream from InputStream and OutputStream.
Do you even need endOfStream? From my experience, it's ok to
blocked-read and determine end when 0 is read. Even if you read from
network, is there a point in non-blocking read?
Probably, I think I'll try both ways and see which one turns out to be
better.
I should say, that implementation will be somewhat tricky, as different kinds
of streams handle reads beyond end in different ways. Say, reading from a pipe
whose write end is closed results in an error.
Either way is fine with me. But I agree yours is handy, too.
I was actually thinking about a plain ubyte[] read(); method:
struct BufferedStream
{
ubyte[] read(); // just give me something
}
Funny idea.
Here we can also think about MemoryStream: when you have all the data in
memory, you don't need user side buffer, and can just return direct slice to
data as const(ubyte)[].
We've circled all the way back to ranges a la byChunk.
bool empty();
ubyte[] front();
void popFront();
Look ma, no copying, no fuss, no muss.
Whatever interface(s) we find work best for various kinds of streams, we
should make them play nice with ranges. Burst streams (the kind that
offer data in variable-size chunks) work great with a range interface.
Andrei
