On 9/3/11 3:54 PM, Andrei Alexandrescu wrote:
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Here are a few points following a pass through the dox:
* After thinking some more about it, I find the approach seek() plus
enumerated Anchor undesirable. It's a bad case of logical coupling as
one never calls seek() passing an anchor as a variable. It's really
three functions - seekForward, seekBackward, and seekAbsolute. Heck,
knowing what seek does, it should be just seekAbsolute. But then there
are several possible designs; a logically coupled seek() is not a good
turn in any case.
* Seekable should document that tell() is O(1) and seek() can be
considered O(1) but with a large constant factor.
* Why is close() not part of Seekable, since Seekable seems to be the
base of all streams?
* Class File is IMHO not going to cut the mustard. It needs to be a
struct with a destructor. One should be able to _get_ an InputStream or
an OutputStream interface out of a File object (i.e. a file is a factory
of such interfaces), but the File itself must be a struct.
* I don't understand the difference between read() and readComplete().
* readUntil is a bit tenuous. I was hoping for a simpler interface to
buffered streams, e.g. just expose the buffer as a ubyte[].
* readUntil(const(ubyte)[]) does not give a cheap means to figure
whether the read ended because file ended or the terminator was met.
* There's several readUntil but only one appendUntil. Why?
* Document the difference between skip and seek. Also, skip should take
a ulong.
* I see encoder and decoder() in DInput, should both be decoder?
* StreamWidth, TextXXX and friends are a bit sudden because they
introduce a higher-level abstraction in a module so far only preoccupied
to transferring bytes. I was thinking that kind of stuff would belong to
a formatter/serializer module.
Overall, there are interesting elements in this proposal but I don't
quite feel it hit the proverbial nail on the head.
Andrei
