On 2/18/16 12:08 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 15:44:00 UTC, Steven Schveighoffer wrote:
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven Schveighoffer
wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
why isn't that used more especially with e.g. window?
After all, window seems like a very well used word...
Not sure what you mean.
I don't like that a stream isn't inherently an input range.
This seems to me like a good place to use this abstraction by default.
What is front for an input stream? A byte? A character? A word? A line?
Why not just say it's a ubyte and then compose with ranges from there?
If I provide a range by element (it may not be ubyte), then that's
likely not the most useful range to have.
I hadn't thought of this before, but if we accept that a stream is raw,
untyped data, it may be best _not_ to provide a range interface
directly. It's easy enough to
alias source = sourceStream.as!ubyte;
anyway, right?
An iopipe is typed however you want it to be.
bufferedInput by default uses an ArrayBuffer!ubyte. You can have it use
any type of buffer you want, it doesn't discriminate. The only
requirement is that the buffer's window is a random-access range
(although I'm having thoughts that I should just require it to be an array).
But the concept of what constitutes an "item" in a stream may not be the
"element type". That's what I'm getting at.
This is why I think it's better to have the user specifically tell me
"this is how I want to range-ify this stream" rather than assume.
I think this makes more sense with TLV encodings, too. Thinking of
things like:
switch(source.as!(BERType).popFront){
case(UNIVERSAL|PRIMITIVE|UTF8STRING){
int len;
if(source.as!(BERLength).front & 0b10_00_00_00) {
// X.690? Never heard of 'em!
} else {
len = source.as!(BERLength).popFront;
}
return source.buffered(len).as!(string).popFront;
}
...etc.
}
Very cool looking!
However, you have some issues there :) popFront doesn't return anything.
And I think parsing/processing stream data works better by examining the
buffer than shoehorning range functions in there.
-Steve
