On Thursday 18 July 2002 09:30 pm, Guido van Rossum wrote:
> > I suspect read and write would best be kept on separate
> > interfaces. Ability to read, write, seek-and-tell, being three
> > atoms of which it makes sense to have about 6 combos
> > (R, W, R+W, each with or without S&T). Rewind might
> > make sense separately from S&T if streaming tapes were still in
> > fashion and OS's gave natural access to them.
>
> 5, because R+W without S&T makes little sense.
Reasonably little, yes -- hard to make up a non-contrived example
('preserve data up to the first occurrence of "bzz" and then overwrite
the rest of the file with "spam"'...?-).
> > But I do think it's all pretty academic.
>
> C++ has tried very hard to do this with its istream, ostream and
> iostream classes; I believe I heard C++ people say once that it's not
> considered a success.
As a C++ person I agree. It's better by far than C, mind you -- for
text I/O, at least -- but it's complex and intricate.
> I believe Java has tried to address this too.
> What do you think of Java's solution?
In the only time in my life when I was using Java in earnest (in code
intended for production purposes, though think3 later dropped the
idea), Java hit me with a deprecation to the solar plexus exactly in
this area, forcing me to do much unproductive rewriting -- so I find
it hard to be unbiased. But even striving to be fair, I don't see the
advantage compared e.g. to C++'s streams.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4