Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
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 java.io 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 java.io 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 caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners