On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:
[...]
Well, given your example, I would strongly argue that you
should write a range that calls read in its constructor and in
popFront rather (so that calling front multiple times doesn't
matter) rather than using map. While map can theoretically be
used the way that you're trying to use it, it's really intended
for converting an element using rather than doing stuff like
I/O in it. Also, if the range that you give map is random
access (like an array would be), then opIndex could be used to
access random elements, which _really_ wouldn't work with
reading from a file. So, I think that map is just plain a bad
choice for what you're trying to do.
Well, I used map because of when viewing the scenario in a data
flow, map seems an intuitive choise:
what I have: a bunch of large files, each file containing
sections of data, each sections is composed of many lines of
record. For each file, I have an list of indices.
what I want: given a list of files and indices for each file, I
want to construct a lazy stream of records for other program to
use.
here is the data flow:
query constraints
-> [(filePath, [index])]
-> [(File, [index])] // map, needs cache
-> [[section]] // map, needs cache
-> [[[record]]] // joiner.joiner
-> Range of record
And after reading cache's docs, I get that cache is perfect for
converting a Range with front side effect into a Range with
popFront side effect.
So if cache and map works harmoniously, they should do the same
trick as manually writing two Ranges here.
- Jonathan M Davis
