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