Jump to page: 1 27  
Page
Thread overview
deprecating std.stream, std.cstream, std.socketstream
May 13, 2012
Walter Bright
May 13, 2012
Nathan M. Swan
May 13, 2012
Kiith-Sa
May 13, 2012
Nathan M. Swan
May 13, 2012
Walter Bright
May 15, 2012
Jonas Drewsen
May 13, 2012
Nathan M. Swan
May 14, 2012
Andrej Mitrovic
May 14, 2012
Robert Clipsham
May 14, 2012
Oleg Kuporosov
May 15, 2012
Walter Bright
May 14, 2012
Stewart Gordon
May 15, 2012
Walter Bright
May 15, 2012
Walter Bright
May 15, 2012
Nathan M. Swan
May 16, 2012
Sean Kelly
May 16, 2012
Christophe Travert
May 16, 2012
Walter Bright
May 16, 2012
Sean Kelly
May 16, 2012
Walter Bright
May 16, 2012
H. S. Teoh
May 16, 2012
Walter Bright
May 16, 2012
Robert Clipsham
May 16, 2012
Dmitry Olshansky
May 16, 2012
Walter Bright
May 16, 2012
Stewart Gordon
May 16, 2012
H. S. Teoh
May 16, 2012
Stewart Gordon
May 16, 2012
Walter Bright
May 16, 2012
Stewart Gordon
May 16, 2012
Walter Bright
May 16, 2012
Timon Gehr
May 16, 2012
Adam D. Ruppe
May 16, 2012
H. S. Teoh
May 16, 2012
H. S. Teoh
May 16, 2012
H. S. Teoh
May 16, 2012
jerro
May 16, 2012
Artur Skawina
May 16, 2012
Artur Skawina
May 16, 2012
Adam D. Ruppe
May 15, 2012
Walter Bright
May 15, 2012
H. S. Teoh
May 15, 2012
Walter Bright
May 15, 2012
Dmitry Olshansky
May 13, 2012
This discussion started in the thread "Getting the const-correctness of Object sorted once and for all", but it deserved its own thread.

These modules suffer from the following problems:

1. poor documentation, dearth of examples & rationale

2. toHash(), toString(), etc., all need to be const pure nothrow, but it's turning out to be problematic for doing it for these classes

3. overlapping functionality with std.stdio

4. they should present a range interface, not a streaming one
May 13, 2012
On 13-05-2012 23:38, Walter Bright wrote:
> This discussion started in the thread "Getting the const-correctness of
> Object sorted once and for all", but it deserved its own thread.
>
> These modules suffer from the following problems:
>
> 1. poor documentation, dearth of examples & rationale
>
> 2. toHash(), toString(), etc., all need to be const pure nothrow, but
> it's turning out to be problematic for doing it for these classes
>
> 3. overlapping functionality with std.stdio
>
> 4. they should present a range interface, not a streaming one

I'm all for it. I haven't used any of them, ever, and probably never will. Their APIs aren't particularly appealing, honestly.

-- 
- Alex
May 13, 2012
On Sunday, 13 May 2012 at 21:39:07 UTC, Walter Bright wrote:
> 4. they should present a range interface, not a streaming one

I was just about to make a post suggesting that! You could easily integrate std.io with std.algorithm to do some pretty cool things.

NMS
May 13, 2012
On Sunday, 13 May 2012 at 21:39:07 UTC, Walter Bright wrote:
> This discussion started in the thread "Getting the const-correctness of Object sorted once and for all", but it deserved its own thread.
>
> These modules suffer from the following problems:
>
> 1. poor documentation, dearth of examples & rationale
>
> 2. toHash(), toString(), etc., all need to be const pure nothrow, but it's turning out to be problematic for doing it for these classes
>
> 3. overlapping functionality with std.stdio
>
> 4. they should present a range interface, not a streaming one


My D:YAML library (YAML parser) depends on std.stream
(e.g. for cross-endian compatibility and loading from memory),
and I've been waiting for a replacement since the first release.

I support removing std.stream, but it needs a replacement with
equivalent functionality.

Actually, I've postponed a 1.0 release _until_ std.stream is replaced.
May 13, 2012
On Sunday, 13 May 2012 at 21:53:58 UTC, Kiith-Sa wrote:
> My D:YAML library (YAML parser) depends on std.stream
> (e.g. for cross-endian compatibility and loading from memory),
> and I've been waiting for a replacement since the first release.

We also need better interfacing with UTFs in that. D is usually great at Unicode, but it doesn't interface well with I/O. For example, when working on the file-reader for SDC I had to hand-code the check-BOM-read-and-convert functions: http://bit.ly/J0QWVF .

Trying to make it read lazily is even harder, as all std.utf functions work on arrays, not ranges. I think this should change.

NMS
May 13, 2012
On Sunday, 13 May 2012 at 21:53:58 UTC, Kiith-Sa wrote:
> My D:YAML library (YAML parser) depends on std.stream
> (e.g. for cross-endian compatibility and loading from memory),
> and I've been waiting for a replacement since the first release.

We also need better interfacing with UTFs in that. D is usually
great at Unicode, but it doesn't interface well with I/O. For
example, when working on the file-reader for SDC I had to
hand-code the check-BOM-read-and-convert functions:
http://bit.ly/J0QWVF .

Trying to make it read lazily is even harder, as all std.utf
functions work on arrays, not ranges. I think this should change.

NMS
May 13, 2012
On 5/13/2012 3:16 PM, Nathan M. Swan wrote:
> Trying to make it read lazily is even harder, as all std.utf functions work on
> arrays, not ranges. I think this should change.

Yes, std.utf should be upgraded to present range interfaces.
May 14, 2012
On 13/05/2012 22:38, Walter Bright wrote:
> This discussion started in the thread "Getting the const-correctness of
> Object sorted once and for all", but it deserved its own thread.
>
> These modules suffer from the following problems:
>
> 1. poor documentation, dearth of examples & rationale
>
> 2. toHash(), toString(), etc., all need to be const pure nothrow, but
> it's turning out to be problematic for doing it for these classes
>
> 3. overlapping functionality with std.stdio
>
> 4. they should present a range interface, not a streaming one

I make use of std.stream quite a lot... It's horrible, it has to go.

I'm not too bothered if replacements aren't available straight away, as it doesn't take much to drop 10 lines of replacement in for the functionality I use from it until the actual replacement appears.

-- 
Robert
http://octarineparrot.com/
May 14, 2012
On Sunday, 13 May 2012 at 21:39:07 UTC, Walter Bright wrote:

> 3. overlapping functionality with std.stdio

unfortunatelly std.stdio under Windows couldn't handle UTF16(wchar)-based file names and text IO which are naturel there. The root of issues looks in both underlying DMC C-stdio (something wrong with w* based functions?) and std.format which provides only UTF8 strings. It make sense to depreciate for reasons but only after std.stdio would support UTF16 names/flows or good replacement (Steven's std.io?) would be ready. Currently std.[c]stream is only the way to work with UTF16 filesystems in Phobos. Or switch to Tango which looks supports it too (but I don't have expirience here).


May 14, 2012
On 5/13/12, Kiith-Sa <42@theanswer.com> wrote:
> My D:YAML library (YAML parser) depends on std.stream

Also ae.xml depends on it.
« First   ‹ Prev
1 2 3 4 5 6 7