Re: [Caml-list] Re: Common IO structure

[Benjamin Geer <ben@socialtools.net>]

John Goerzen wrote:
> We were talking about being intuitive here.  I'd have to read maybe a
> dozen different class descriptions, have to understand the differences
> between them, and cross-reference back and forth between them to figure
> out how to get the object I want.  Or pay for a Java book that describes
> these relationships itself.

No, you just need a little tutorial; Sun has a good free one online:

http://java.sun.com/docs/books/tutorial/essential/io/index.html

> Everybody I worked with had the Javadoc for the API bookmarked and
> referred to it constantly.

I've always done that in all programming languages.  I have more 
important things to remember than all the little details of all the APIs 
I use.

> Here's one of the problems.  Java's API makes it complex to do simple
> things without simplifying complex things.  Recall my example -- being
> able to open a file read/write and seeking around in it?  In C, I'd do:
> 
>    int file = open(filename, O_RDWR) or FILE * file = fopen(filename, "r+")
> 
> Perl, it is:
>  
>    open(FH, "+<", $filename)
> 
> Or, in Python:
> 
>    file = open(filename, "r+")

How are any of those simpler than the Java example I gave you:

RandomAccessFile file = new RandomAccessFile(filename, "rw");

> Java requires me to wade through and think about all of these things
> plus the way the file will eventually be used (do I want an array of
> bytes, an array of chars, strings, etc?) right when I open it.

If you want to open a file for reading, you have this in Java:

InputStream in = new FileInputStream(filename);

That's all; you're ready to read bytes.  If you want to convert bytes 
into characters, you can make that decision later:

Reader inReader = new InputStreamReader(in);

That will use your system's default character encoding.  Since this is a 
common case, Java provides a convenience class as a shortcut (no 
InputStream needed):

Reader inReader = new FileReader(filename);

On the other hand, suppose you're reading data that's compressed in Zip 
format?  Given any InputStream (from a socket, a file, or whatever), you 
can wrap it in a ZipInputStream, which knows how to decompress a Zip file:

ZipInputStream zIn = new ZipInputStream(in);

Wasn't that easy?

> for line in open(filename, "r").xreadlines():
>     print line
> 
> See what I mean about intuitive?

I don't find it intuitive for every 'file-like object' (i.e. stream or 
channel) to know about character encodings and assume that it can 
meaningfully chop its data up into lines.  In many cases (e.g. when 
dealing with image or audio files) that assumption will be false.  It 
seems more intuitive to me to have character encodings (and compression, 
encryption, and all other transformations of bytes) in separate, 
optional layers.

Ben

-------------------
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