Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] [ANN] The Missing Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-28 (21:44)
From: John Goerzen <jgoerzen@c...>
Subject: Re: [Caml-list] Re: Common IO structure
On Wed, Apr 28, 2004 at 10:30:13PM +0100, Benjamin Geer wrote:
> >>the new one (java.nio)[2].  The old one has the virtue of being easy to 
> >>understand and use, and flexible enough for many situations.  The basic 
> >
> >Uh, no.  I don't have the API reference in front of me,
> I provided links to it in the very message you're replying to.
> >but I seem to
> >recall somewhere around a dozen or so predefined classes for doing
> >I/O...
> I've been using every day for several years, and I find those 
> classes simple and intuitive, particularly the layered approach of using 
> wrappers to add functionality to stream objects, as Nicholas Cannasse 
> points out in another message.

I'm looking at right now.  I count no less than 10 interfaces
and 50 classes.  Let's say that I want to open up a file for read/write
access and be able to seek around in it.  Looking at the class list, I
don't know if I want BufferedInputStream, BufferedOutputStream,
BufferedReader, BufferedWriter, CharArrayReader, CharArrayWriter,
DataInputStream, DataOutputStream, File, FileDescriptor,
FileInputStream, FileOutputStream, FileReader, FileWriter, InputStream,
InputStreamReader, OutputStream, OutputStreamWriter, RandomAccessFile,
Reader, or Writer.  Really, I literally *do not know how to open a
simple file*.  I would not call that intuitive.  Even OCaml, for all its
faults, makes that easier (and that's after I've already found the
function I need in Unix!)

> >Python is simple.  One standard for everything.  You get read(),
> >write(), readline(), readlines(), xreadlines() (hello Extlib, this one's
> >for you), seek(), etc.  This can apply to files, strings, sockets,
> >pipes, whatever.  Before we can start fussing about unicode
> >abstractions, I think we need to have a uniform I/O layer.
> OK, but then you can leave out readline(), readlines() and xreadlines(), 
> because they don't make any sense unless you've already dealt with 
> character encodings.

No, they can simply be implemented in terms of read().

> Then, before you can divide text into lines, you also need to know which 
> newline character(s) to use.  This needs to be configurable 
> programmatically rather than guessed based on the platform the program 
> is running on; some protocols require you to use \r\n regardless of the 
> platform.

That's pretty easy as a class variable, not to mention that \r\n or \n
line-endings can be automatically handled in a reliable way if used
uniformly throughout a file.

-- John

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: