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

On Sat, Sep 3, 2011 at 12:54 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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
>

Interesting. How does this work with RAII? Where is the source code?

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> 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

After a quick look, I have two concerns:

1.  File is a class, not a struct.  This precludes using reference counting as the current std.stdio.File does, meaning you have to close all your Files manually.  I loved the reference counting semantics, especially the last few releases since most of the relevant compiler bugs have been fixed.

2.  File(someFileName, someMode) needs to work.  Not supporting this method of instantiating a File object would break way too much code.

On 09/03/2011 09: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
>

File is now a class. This will break a lot of code.
What is happening to the refcounted File feature? It seems that the new way of file handling, using a file class, is more error prone than the old way?

But it is really great to hear that the efficiency problems of std.stdio are being sorted out!

On 2011-09-03 19:54:05 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> 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

Looks good…

Hum, inconsistent casing of enum members.

And shouldn't there be a way to do non-blocking IO? ;-)

I like that File is now a class because it's cleaner that way, but non-deterministic destruction is going to be a problem. That said, it was already a problem anyway if you stored a File struct in a class, so maybe we need a more general solution for reference-counted classes.

Class names DInput and DOutput sounds silly. If all classes implemented purely in D had a D prefix, it'd get redundant pretty fast (like KDE apps beginning in K). I'd suggest BufferedInput and BufferedOutput, or something else that actually describes what the class does, instead of DInput and DOutput. And I'd make them final, that way there won't be any virtual call overhead until the buffer needs to be replenished or flushed from the wrapped input or output stream.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Actually I'll generalize the comment I made before:  As much as I like more efficiency, I despise the massive overhaul and code breakage and the complexity of having a zillion tiny objects to do everything that File used to do.  I would like to see the native I/O under the hood plus something more like the current API for basic file I/O.  I'd vote against the current design just because of the massive code breakage it would cause with no migration plan.

On 9/3/11 11:20 PM, dsimcha wrote:
> 2.  File(someFileName, someMode) needs to work.  Not supporting this method of
> instantiating a File object would break way too much code.

This one could easily be solved by aliasing File.open to (static) opCall().

David

== Quote from David Nadlinger (see@klickverbot.at)'s article
> On 9/3/11 11:20 PM, dsimcha wrote:
> > 2.  File(someFileName, someMode) needs to work.  Not supporting this method of instantiating a File object would break way too much code.
> This one could easily be solved by aliasing File.open to (static) opCall().
> David

Agreed, but in the big picture this overhaul still breaks way too much code without either a clear migration path or a clear argument about why such extensive breakage is necessary.  The part about File(someFileName, someMode) is just the first thing I noticed.

I dislike naming things with a leading "D" like "DInput". Shouldn't we keep code that relies on C to be put in etc.c or somewhere?

Also, changing structs to classes is gonna *massively* break code
everywhere. Why inheritance instead of a predicate like isInputStream
= is(typeof(T t; t.put; t.close)), you know the drill..