I understand this concern. Nowadays I have found use for a different
concept - range with history. With such a range you can return in "time"
to positions that you've visited before. There's also the concept of
"lookahead", i.e. a range that you can move to later points in time.
A seekable file would be a range with both history and lookahead.
Anyway, such adaptors are generally useful - I was thinking of defining
Lookbehind(Range) and Lookahead(Range) in std.range. They'd use RAM for
caching.
Andrei
On 07/05/2010 11:57 AM, Michel Fortin wrote:
Le 2010-07-05 à 12:23, Andrei Alexandrescu a écrit :
On 07/05/2010 11:14 AM, Michel Fortin wrote:
But I have to admit the ability of a range to seek outside of the range's range
(like rewinding) seems a little odd. It does fit better with a 'stream' concept.
Ranges are streams!
I'm not contesting that (at this time). What I meant is that allowing a range
to seek beyond its bounds looks counter nature to me. If it was called a stream
it wouldn't be so bad. It's mostly a naming thing.
For instance, let's say I have a file with this content:
[0,1,2,3,4,5,6,7,8,9];
I call popFront 5 times, so the content of the range conceptually becomes this:
[5,6,7,8,9];
Then I call a function, say seek(2), to return to the third element. Does this
add back elements in my range?
[2,3,4,5,6,7,8,9]
Adding back elements to a range seems quite un-range-like to me. Seeking to a position
relative to the first element in the "container" (the file) would be even more
so.
Now call it a stream and it looks more natural to do these operations. But
perhaps it's only me.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
