On Friday, March 11, 2011 16:27:21 dsimcha wrote: > On 3/11/2011 7:12 PM, Stewart Gordon wrote: > > On 10/03/2011 04:53, dsimcha wrote: > > <snip> > > > >> I'd like to get some comments on what an appropriate API design and > >> implementation for > >> writing gzipped files would be. Two key requirements are that it must > >> be as easy to use as > >> std.stdio.File and it must be easy to extend to support other > >> single-file compression > >> formats like bz2. > > > > You don't seem to get how std.stream works. > > > > The API is defined in the InputStream and OutputStream interfaces. > > Various classes implement this interface, generally through the Stream > > abstract class, to provide the functionality for a specific kind of > > stream. File is just one of these classes. Another is MemoryStream, to > > read to and write from a buffer in memory. A stream class used to work > > with gzipped files would be just another. > > > > Indeed, we have FilterStream, which is a base class for stream classes > > that wrap a stream, such as a file or memory stream, to modify the data > > in some way as it goes in and out. Compressing or decompressing is an > > example of this - so I guess that GzipStream would be a subclass of > > FilterStream. > > > > Stewart. > > But: > > 1. std.stream is scheduled for deprecation IIRC.
Technically speaking, I think that it's intended to be scheduled for deprecation as opposed to actually being scheduled for deprecation, but whatever. It's going to be phased out as soon as we have a replacement.d > 2. std.stdio.File is what's now idiomatic to use. Well, more like it's the only solution we have which will be sticking around. Once we have a new std.stream, it may be the preferred solution. > 3. Streams in D should be based on input ranges, not whatever crufty > old stuff std.stream is based on. Indeed. But the new API still needs to be fleshed out and implemented before we actually have even a _proposed_ new std.stream, let alone actually have it. - Jonathan M Davis