On 03/30/2010 06:03 AM, Steve Schveighoffer wrote:
Can you detail the reader/writer operations? Because popNext and front ain't gonna cut it for streams. Most of the time the element size you want is defined by the application (and not easily abstracted), not the range, but the range is in charge of the element size (via front).
I think there's no necessity that a range has a constant-size element type. If the element type of the range is e.g. ubyte[], then it can be free to transfer as much data as it wants at each popFront().
While I believe ranges can be useful for streams, they are not the best interface for all applications. For example, if I have a protocol that reads 2 bytes to get a length, and then reads length bytes from the stream, a range of those units is probably a good abstraction. But I don't want to resort to C calls to create that abstraction -- there should be a nice D layer in between. I should not have to create my own buffering solution. I/O performance is more important IMO than interface when it comes to streams. This does not mean big-O complexity, I'm talking about raw performance.
I think the interface you described can be easily modeled as a range of ubyte[]. Again, a range of ubyte[] doesn't have to return the same number of elements each step.
I hope we can see a design before you commit to doing it this way. For example, a zip library uses a range as a source, what does the file range look like that satisfies the range properties and also is efficient? Just seeing the API should be enough to judge.
Feel free to suggest one. I won't be able until I study the zip file format.
And are there plans to make a good abstracted library for streams that custom ranges can be built upon?
Not sure I understand this. Andrei _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
