On 2010-08-08 14:11, Mafi wrote:
Hi all,
what are the directions of D2's streams. I heared std.stream is going to
get deprecated in D2. I think it's good as long as
BufferedFile.readLine() returns char[] instead of string. Is D2 going to
get a Java-like stream model? What's wrong with the old one except that
it's a bit out of date?
Mafi
AIUI from the discussion under the topic "Network I/O and streaming in
D2" the whole I/O will go through std.stdio.File, which looks great for
a closed set of possible streams, but I'm afraid that it won't be
sufficiently extensible for some cases.
Like many people, I found Java stream model bloated.
However, in my opinion, Stream makes it possible to extend I/O subsystem
at library level with custom streams, while still having common
(standard!) interface to them, and a possibility to use a fair amount of
already implemented operations like reading/writing various primitive
types and arrays, at very small cost of implementing only a constructor
and read/write primitives.
In my modest experience, I found std.stream.Stream a good solution in
some cases: once the application could have a common interface for both
secure and raw network stream (the first being a custom stream, which
wrapped OpenSSL SSL structures, and the second being SocketStream from
std.socketstream). Another case is what I'm currently developing - a
library for accessing 8-bit Atari disk images. There are a few different
filesystems possible inside such images, and for each one there will
be a different translation between image contents and file operations,
but the file operations should be hidden behind a common interface.
Again, Stream seemed the best choice for me - firstly, it comes from
standard library; secondly, it requires only readBlock and writeBlock to
be implemented, and the rest is already done.
I also wondered if things like DirIterator and DirEntry could also be
interfaces (I wrote my own interfaces for this purpose), but these could
be of much less usage.
To sum up, I think it's worth saving Stream as a common interface for
I/O, but it possibly needs some improvements in details. For example,
instead of having its own File class, conflicting with std.stdio.File,
it could simply wrap std.stdio.File into, let's say, FileStream or sth.
Another thing would be making the set of methods resembling that of
std.stdio.File. It would be nice to use std.stdio.File when you don't
need extensibility, but have an option to easily move to descendants of
std.stream.Stream without changing every single call.
What are your opinions?
Adrian
