File Api [Was: [your code here]]

[H. S. Teoh]

On Fri, Feb 17, 2012 at 09:20:59PM -0500, bearophile wrote:
> H. S. Teoh:
> 
> > P.S.S. The .idup is a bit ugly, but necessary, since apparently
> > byLine() calls readln() with a static buffer, so choice will be
> > silently overwritten if the .idup is omitted.
> 
> An alternative File API that to me looks nice. This is a first part,
> it's for scripting-like or not high performance purposes, it looks
> essentially like Python code, every line is a newly allocated string:
> 
> import std.stdio;
> void main() {
>     string[] lines;
>     foreach (line; File("data.dat")) {
>         static assert(is(line == string));
>         lines ~= line;
>     }
> }

I don't think it's a good idea to have File() automatically iterate by
lines. What if data.dat is binary? I think it's still better to have:

	foreach (line; File("...").lines()) { ... }

where File.lines() is a lazy method that reads the file line-by-line.

For binary files, you could have File.byChunk!T() where T can be any
type, struct, etc., with the appropriate method for construction on
input.


> If you don't want a new buffer every line you use something like this:
> 
> import std.stdio;
> void main() {
>     string[] lines;
>     foreach (line; File("data.dat").fastLines()) {
>         static assert(is(line == char[]));
>         lines ~= line.idup;
>     }
> }
> 
> So on default it's handy, short and safe, and with a method you avoid
> an allocation every line and get a mutable char[].

Makes sense.


> Maybe even this works, downloads a page and scans its lines, but maybe
> it's better to add a bit of extra safety to this:
> foreach (line; File("http://www.dlang.org/faq.html")) {}
[...]

I don't know about this, I would prefer downloading files to be in
another class, not File. As long as they provide a Range interface it's
good enough. Perhaps File and NetworkFile (or whatever you want to call
it) can implement the same interface, .lines() for safe iteration,
.fastLines() for buffered iteration.

Anyway, is anyone working on a new file I/O interface? I'd like to see
std.stream and std.stdio combined, for one thing. Or replaced with a
range-based API.


T

-- 
Frank disagreement binds closer than feigned agreement.