On Mon, 14 May 2012 22:56:08 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 5/14/2012 8:02 AM, Steven Schveighoffer wrote:
I keep trying to avoid talking about this, because I'm writing a
replacement
library for std.stream, and I don't want to step on any toes while it's
still
not accepted.
But I have to say, ranges are *not* a good interface for generic data
providers.
They are *very* good for structured data providers.
In other words, a stream of bytes, not a good range (who wants to get
one byte
at a time?). A stream of UTF text broken into lines, a very good range.
I have no problem with getting rid of std.stream. I've never actually
used it.
Still, we absolutely need a non-range based low-level streaming
interface to
data. If nothing else, we need something we can build ranges upon, and
I think
my replacement does a very good job of that.
I'll say in advance without seeing your design that it'll be a tough
sell if it is not range based.
I've been doing some range based work on the side. I'm convinced there
is enormous potential there, despite numerous shortcomings with them I
ran across in Phobos. Those shortcomings can be fixed, they are not
fatal.
The ability to do things like:
void main() {
stdin.byChunk(1024).
map!(a => a.idup). // one of those shortcomings
joiner().
stripComments().
copy(stdout.lockingTextWriter());
}
I think we may have a misunderstanding. My design is not range-based, but
supports ranges, and actually makes them very easy to implement.
byChunk is a perfect example of good range -- it defines a specific
criteria for determining an "element" of data, appropriate for specific
situations.
But it must be built on top of something that allows reading arbitrary
amounts of data. At the lowest level, this is the OS file
descriptor/HANDLE.
To be efficient, it should be based on a buffering stream. That buffering
stream *does not* need to be a range, and I don't think shoehorning such a
construct into a range interface makes any sense.
To make this clear, I can say that any range File supports, my design will
support *as a range*.
To make it even clearer, the current std.stdio.File structure, which you
have shown to "kick ass" with ranges, is *NOT* range-based by my
definition.
I should note, the output range idiom is directly supported, because the
output range definition exactly maps to an output stream definition.
-Steve
