On Sat, 03 Sep 2011 21:23:26 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 9/3/2011 3:53 PM, dsimcha wrote:
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.
[rant]
I agree. I agree that std.stream should be replaced, but I have a lot of
misgivings about replacing std.stdio. I do not want to rewrite every
darn D program I've ever written. I think it is a bad idea to break
everyone else's D program.
Everything in dsource will break in non-trivial ways. I don't think we
can afford this. I do not know of any successful system or language that
breaks user code with such aplomb as D does. Not even C++ dares to break
that Piece Of S*** that everyone knows iostreams is. I can compile and
run unix C code from 30 years ago on Linux with no changes at all. Same
with DOS code.
There needs to be huge improvement to justify such breakage.
[I also don't like it that all my code that uses std.path is now broken.]
I would prefer to see all the energy that is going into refactoring
existing, working modules go into designing new, not existing, modules
that there's a crying need for.
[/rant]
Please, leave all pitchforks and torches at rest for the moment :) I want
to stress, this is *NOT* a proposal for inclusion or generating a pull
request tomorrow. It's a very very early version, almost a proof of
concept, to show *why* we need to change things. Most of the library is
up for debate. I agree it needs to be more compatible with current code.
In hindsight, I probably should have said no when Andrei asked to post
this on the NG, and did it myself when I could stress the state of it.
The two most important things are:
1. the interface additions, in particular the readUntil portion (which I
think provides a very powerful interface for parsing systems).
2. the performance. It's much better than current stdio. Aren't people
continuously complaining at how slow i/o is in Phobos compared to other
libraries?
Enough ranting for now, as for the proposed std.stdio,
1. It does look fairly straightforward, but:
2. There is only one example. Have any commonly done programming tasks
been tried out with it to see how they work?
My main testing has been for:
1. utf input/output correctness of all formats
2. implementing readf/writef
3. testing performance.
I have not written any "real world" tests. Probably the most interesting
tests I've written are reading a UTF-X file and writing the data to a
UTF-Y file (where X and Y are one of UTF-8, UTF-16LE, UTF-16BE, UTF-32LE,
UTF-32BE).
3. There is no indication of how it interacts with C stdio. A primary
goal of std.stdio was interoperability with C stdio.
useCStdio();
4. There are no benchmarks. The current std.stdio was designed/written
in parallel with some benchmarks Andrei and others cooked up, as a
primary goal was performance.
I can include these.
5. flushCheck - flushing should be done based on the file type. tty's
should be \n flushed, files when the buffer is full. I question the
performance of using a delegate to check for flushing. How often will it
be called?
Once per write to the buffer. Data is only checked once (the delegate is
never given the same data to check again). If you want, I can look at
adding a means to avoid using a delegate when the trigger is a single
character.
And TextInput/TextOutput auto detect whether a device is a tty, and
install the right flushcheck function if necessary.
6. There is no provision for multithreaded writing, i.e. what happens
when two threads write to stdout. Ideally, there should be a way to
'lock' the stream to oneself, in order to appropriately interleave the
output.
Again, I wish I had not told Andrei to post :( Multithreaded is not
supported, but will be. When that is ready, a locking mechanism (and
hopefully an auto-unlock mechanism) will be provided.
7. I see nothing for 'raw' character by character input.
The interface is geared to read by processing the buffer, not one
character at a time. Given access to the buffer, you can process one
character at a time if you want.
See InputRange in TextInput to see how raw character-by-character input
can be done.
That being said, I think I need to add a peek function.
8. I see nothing for determining if a char is available on the input.
How would one implement "press any key to continue"?
I need more information. I would probably implement this as a
read(ubyte[1]), so I don't see why it can't be that way.
-Steve
