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 EAA01559; Fri, 30 Apr 2004 04:37:58 +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 EAA01236 for ; Fri, 30 Apr 2004 04:37:56 +0200 (MET DST) Received: from gatekeeper.elmer.external.excelhustler.com (gatekeeper.excelhustler.com [68.99.114.105]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3TKfiSH022028 for ; Thu, 29 Apr 2004 22:41:45 +0200 Received: from chatterbox.elmer.internal.excelhustler.com (unknown [192.168.0.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "chatterbox.elmer.internal.excelhustler.com", Issuer "excelhustler.com" (not verified)) by gatekeeper.elmer.external.excelhustler.com (Postfix) with ESMTP id D0FB3E0247; Thu, 29 Apr 2004 15:41:39 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 717965C006; Thu, 29 Apr 2004 15:41:39 -0500 (CDT) Received: from wile.internal.excelhustler.com (wile.internal.excelhustler.com [192.168.1.34]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 3AC775C005; Thu, 29 Apr 2004 15:41:39 -0500 (CDT) Received: by wile.internal.excelhustler.com (Postfix, from userid 1000) id 296B324079; Thu, 29 Apr 2004 15:41:39 -0500 (CDT) Date: Thu, 29 Apr 2004 15:41:39 -0500 From: John Goerzen To: Benjamin Geer Cc: Richard Jones , caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure Message-ID: <20040429204139.GA21608@excelhustler.com> References: <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> <20040429122305.GA6688@redhat.com> <40911AF6.7020105@socialtools.net> <20040429153538.GA14089@excelhustler.com> <40912369.6010301@socialtools.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40912369.6010301@socialtools.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Scanned-By: clamscan at chatterbox.elmer.internal.excelhustler.com X-Miltered: at concorde with ID 40916888.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 2004:99 2004:99 api:01 instantiate:01 passing:01 compressor:99 java-like:01 python:01 unicode:01 unicode:01 standardized:01 underlying:01 bytes:02 bytes:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, Apr 29, 2004 at 04:46:49PM +0100, Benjamin Geer wrote: > John Goerzen wrote: > >On Thu, Apr 29, 2004 at 04:10:46PM +0100, Benjamin Geer wrote: > >But you do not need a Java-esque API to do that. All you need is a > >standardized File object. You could instantiate one of these by opening > >a file. Or perhaps by passing an existing object to the initializer for > >a gzip decompressor or a Unicode processor. > > The key for me is that I need to be able to chain processing steps > together, so that I can, for example, decompress gzip format and convert > the result to Unicode, a few bytes at a time. This suggests to me that > the gzip compressor and the Unicode processor should themselves be > implementations of the standard File object, so I can wrap a gzip > decompressor around an underlying data source, then wrap the Unicode > decoder around the gzip decompressor. The advantage of this approach is > that the Unicode decoder doesn't know it's dealing with a gzip > decompressor; it only knows it's dealing with something it can read > bytes from. I can then easily remove the decompression step if needed. > And that brings us back to a Java-like approach. If you can think of > a better way of accomplishing this, I'd love to see it. What you have proposed here is exactly what I am proposing and what Python does. It appears we are somehow in complete agreement about what should happen. I guess the disagreement is whether it is like Java. I maintain it is not, since there is a single File object that is used for everything -- both files themselves and various converters. But hey, if you write this and say it's like Java, I'll be happy anyway. -- 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