D2 and stream

[Adrian Matoga]

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