I will come back with some more detailed feedback later on, but a few
nits that caught my eye:
- I don't think changing file from being a struct to a class is a good
idea. First, it breaks an awful lot of D/Phobos programs already out
there, both because of the struct->class change and because of the other
API changes. Second, I feel we should really try to make use of RAII for
things like file handles – I know we have »scope (exit) file.close()«,
but forcing the user to remember to always type that needs a very good
reason, imho. Couldn't File rather have some factory methods returning
stream interface implementations?
- CStream and DInput/Output? I don't care how it is implemented under
the hood, give me something that works! ;) In this case, I guess CStream
is somewhat appropriate, as C (FILE*) streams are widely known, but
still I'm not too fond of the names.
- bufsize -> bufSize?
- Why on earth does DDoc render the enum default parameter as
»(Anchor).Begin«? Is there a bug report for this?
- I am sure there is a reason why the design uses decoder delegates,
but without the source being available, I didn't find it immediately
obvious where the advantages of using it over processing what is being
read() from the stream are. Is this so data can be processed before
going into the buffer? On a related note, what seems to be the decoder
property getter is named »encoder()«.
David
On 9/3/11 9:54 PM, Andrei Alexandrescu wrote:
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio which would
obviate the need for etc.stream and would improve both the generality
and efficiency of std.stdio.
Please chime in with feedback; he's away from the Usenet but allowed me
to post this on his behalf. I uploaded the docs to
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Thanks,
Andrei
