On Monday, 29 June 2015 at 12:00:14 UTC, Jonathan M Davis wrote:
On Sunday, June 28, 2015 11:14:57 Baz via Digitalmars-d-learn
wrote:
On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote:
> I will convert a Java program into D. The original Java code
> is based on the class RandomeAccessFile which essentially
> defines a set of methods for read/write
> Int/Long/Float/String etc. The module std.stream seems to be
> a good fit for this job, but in its documentation, it is
> marked deprecated. So I'd like to know what is the
> replacement for this module. If I don't use this module,
> what is the other apporach I should use. Thanks for help.
You can use std.stream. There is no candidate to replace it.
Even
if tomorrow someone comes with one, it has to be reviewed,
accepted in std.experimental and after a while it would totally
replace the old one.
I think it's safe to say that std.stream will exist for at
least
2 years in its current shape.
No. It was decided at dconf that it was going to be deprecated
and then removed within a relatively short period of time. In
fact, it would have been deprecated with the next release, but
there was a problem with the deprecation and the ddoc build, so
the deprecation was temporarily reverted. But once that's
sorted out, it's going to be deprecated, and it won't be around
much longer at all.
We decided that it was worse to leave it in saying that it was
going to be replaced without having come up with anything for
years than to leave it in. And given that std.stream rarely
even comes up in discussions and that no one has proposed a
replacement, Andrei thinks that it's a sign that there really
isn't much demand for it anyway.
For the most part, simply using std.stdio.File or
std.mmfile.MmFile with ranges does what streams need to do just
fine. Maybe someone will come up with a replacement for
std.stream eventually, but there really doesn't seem to be much
call for it. Regardless, until someone comes up with a
replacement, we're simply not going have a stream-based I/O
(though ranges are close - which is part of why no one has felt
the need to replace std.stream strongly enough to actually do
it).
- Jonathan M Davis
The documentation of std.mmfile.MmFile makes it an unacceptable
replacement for std.stream. I can't even tell if it's features
are missing, or just unintelligible. It rather looks as if you
need to have enough RAM to hold the entire file in memory at
once, but I'm not even sure of that.
Perhaps this is just a documentation problem. Perhaps. But it's
certainly a real problem.
std.stdio.File is a much more reasonable substitute, but the
documentation needs to be improved...probably lifted into a major
heading, perhaps std.stdFile or some such. And examples. As it
is it's buried where it gets overlooked...of course, that would
tend to break any code that depended on using it is where it is
now, so this should be done quickly, or this will end up being a
continuing problem. (Even as it is, much of my code will stop
compiling when this change is finalized, as I have used
std.stream most of the time for years, not knowing of any
alternative.)