May 13, 2012 deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kiith-Sa | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kiith-Sa | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: deprecating std.stream, std.cstream, std.socketstream | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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).
|
Copyright © 1999-2021 by the D Language Foundation