On Sunday, 5 January 2014 at 13:30:59 UTC, Dmitry Olshansky wrote:
I my view text implies something like:
void write(const(char)[]);
size_t read(char[]);
And binary would be:
void write(const(ubyte)[]);
size_t read(ubyte[]);
Should not clash.
Those would do the same thing for either text or binary data.
When I say text writing, I guess I mean the serialization of any
type to text (like what std.stdio.write does):
void write(T)(T value); // Text writing
void write(const(ubyte)[] buf); // Binary writing
write([1, 2, 3]); // want to write "[1, 2, 3]"
// but writes "\x01\x02\x03"
This clashes. We need to be able to specify if we want to
write/read a text representation or just the raw binary data. In
the above case, the most specialized overload will be called.
In-memory array IMHO better not pretend to be a stream. This
kind of wrapping goes in the wrong direction (losing
capabilities). Instead wrapping a stream and/or array as a
buffer range proved to me to be more natural (extending
capabilities).
Shouldn't buffers/arrays provide a stream interface in addition
to buffer-specific operations? I don't see why it would conflict
with a range interface. As I understand it, ranges act on a
single element at a time while streams act on multiple elements
at a time. For ArrayBuffer in datapicked, a stream-style read is
just lookahead(n) and cur += n. What capabilities are lost?
If buffers/arrays provide a stream interface, then they can be
used by code that doesn't directly need the buffering
capabilities but would still benefit from them.
Currently, std.stdio has all three of
those facets rolled into one.
Locking though is a province of shared and may need a bit more
thought.
Locking of streams is something that I haven't explored too
deeply yet. Streams that communicate with the OS certainly need
locking as thread locality makes no difference there.
