On Fri, Dec 17, 2004 at 12:09:34AM +0000, Ben Rudiak-Gould wrote:
Given this background you can probably guess that I'm not too keen on the traditional open/read/write/seek/close model; I don't think it's a good abstraction for anything, even files. I love the idea of gzip and gunzip as transformations on streams, though, and streams backed by memory buffers appear in my proposal too.
The traditional model may be limited, but it's still sufficient for many purposes, and since it's what is supported by the OS, there's something to be said for using it. As a non-library-developer, I must admit that I thought the proposal was pretty nice-looking. In general, I like the idea of creating a standard interface having multiple back ends, and certainly don't see how (for example) viewing a String as a non-seekable read-only file would be at all a bad interface. Of course, you could view it as a seekable read-only file, if you were willing to give up the guarantee of memory-efficient lazy consumption of said string. Presumably you'd need separate classes for binary vs text streams? Since hGetBuf certainly couldn't be used on a String, since it has no binary representation... -- David Roundy http://www.darcs.net