On Fri, 17 Jan 2014 05:01:35 -0500, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
BTW I haven't thought of writing into the buffer, but it works exactly
the same. It could be even read/write -"discarded" data is written to
underlying stream, freshly loaded is read from stream. Now in case of
input stream only writes are nop, for output-only reads are nops.
With pinning it makes for cool multi-pass algorithms that actually
output stuff into the file.
In my experience, the code/process for a write buffer is significantly
different than the code for a read buffer. A read/write buffer is very
difficult to make, because you either need 2 file pointers, or need to
constantly seek the single file pointer to overwrite the existing data.
But as you have it now, isBuffer!OtherBuffer is false. Is this
necessary?
I think I should call it BufferRange from now on. And bring my docs in
line. It may make sense to provide naked Buffer itself as a construct
(it has simpler interface) and have generic BufferRange wrapper. I'm
just not seeing user code using the former - too error prone and
unwieldy.
In a sense, I agree. There aren't many things to do directly with a buffer
(i.e. there will likely be few filters), and a buffer range provides
enough primitives to make front/popFront/empty trivial.
So we can implement buffers that are both ranges and buffers, and will
work with std.algorithm without modification (and that's fine and
expected by me), but do we need to *require* that? Are we
over-specifying?
Random-Access range had to require .front/.back maybe it was
over-specification too? Some stuff is easy to index but not "drop off an
item at either end". But now it really doesn't matter - if there are
such things, they are not random-access ranges.
Is there a possibility that someone can invent a buffer
that satisfies the primitives of say a line-by-line reader, but cannot
possibly be a forward range?
I hardly can see that:
front --> lookahead(1)[0]
empty --> lookahead(1).length != 0
popFront --> seek(1) or enforce(seek(1))
save -> well there got to be a way to pin the data in the buffer?
And they surely could be better implemented inside of a specific buffer
range.
I'll have to take a closer look at your code to have a reasonable
response. But I think this looks fine so far.
-Steve
