From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA20517; Thu, 29 Apr 2004 17:38:26 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA20462 for ; Thu, 29 Apr 2004 17:38:25 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3TFcNjq005362 for ; Thu, 29 Apr 2004 17:38:24 +0200 Received: by rabelais.socialtools.net (Postfix, from userid 108) id BECFA232DF; Thu, 29 Apr 2004 16:38:23 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id A5951232DB; Thu, 29 Apr 2004 16:38:20 +0100 (BST) Message-ID: <40912151.7030302@socialtools.net> Date: Thu, 29 Apr 2004 16:37:53 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: John Goerzen Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure References: <016401c42bc4$b6438840$19b0e152@warp> <20040428.004358.45522587.yoriyuki@mbg.ocn.ne.jp> <016501c42c73$24e64b30$ef01a8c0@warp> <20040428.015800.126758722.yoriyuki@mbg.ocn.ne.jp> <408EEE3E.7050008@socialtools.net> <20040428034415.GB19564@complete.org> <40902265.9040702@socialtools.net> <20040428214442.GE10198@excelhustler.com> <4090E597.1080603@socialtools.net> <20040429132316.GB11323@excelhustler.com> In-Reply-To: <20040429132316.GB11323@excelhustler.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on rabelais.socialtools.net X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 javadoc:01 api:01 apis:01 java's:01 api:01 rdwr:01 python:01 zin:99 encodings:01 chop:01 encodings:01 int:01 simpler:01 bytes:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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