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 QAA27204; Sat, 1 May 2004 16:32:34 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA27033 for ; Sat, 1 May 2004 16:32:33 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i41EWWSH030304 for ; Sat, 1 May 2004 16:32:32 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i41EWSR20393; Sat, 1 May 2004 09:32:28 -0500 (CDT) Date: Sat, 1 May 2004 09:37:45 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Richard Jones cc: Ocaml Mailing List Subject: Re: [Caml-list] Re: Common IO structure In-Reply-To: <20040429122305.GA6688@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 4093B500.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 api:01 analogy:01 damned:01 rtfm:01 api:01 reuse:01 unexpected:01 apis:01 command:98 dump:01 unix:02 classes:03 classes:03 wrote:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Again, sorry for the delay in responding... On Thu, 29 Apr 2004, Richard Jones wrote: > Think of an API as like a user interface. It's a UI for programmers > to use. This is a dangerous analogy, I think. There are several differences. First, I damned well *expect* programmers to be willing to RTFM. Second, and more importantly, take care that in making the API easy to use for the common case you don't make it impossible to use in the odd case. Being able to extend and reuse the library in unexpected ways and in new situations is more important to me as making it easy to use in the common case. Because I inevitably end up in the odd case trying to make the library do something it wasn't designed to do, and discovering you can't do that. This is annoying enough in programs- it's enough to make me dump languages in APIs. And this is one case where we can have our cake and eat it too. My opinion is that the base library should be as flexible as possible- and then we can provide wrapper classes/functions for the common cases. This increases the number of classes and functions, however... The Java.io library has it's drawbacks, I'll freely admit. But the core idea- which is the same core idea as the Unix command line, I comment- is the best I've ever seen for doing I/O. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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