Am Fri, 31 Jul 2009 15:07:10 -0700 schrieb "Brian J. Tarricone" <bj...@cornell.edu>:
> On 07/31/2009 01:59 PM, Mikkel Kamstrup Erlandsen wrote: > > 2009/7/31 Brian J. Tarricone<bj...@cornell.edu>: > >> On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote: > >> > >>> From the looks of it, it should be straight forward to write > >>> GZip{In,Out}putStream classes based on zlib > >> I'd say call it GCompressed{In,Out}putStream and have it either > >> auto-detect the compression type, or have a param in the API to > >> specify from an enum (or both). People can add support for other > >> types of compression as time goes on. > > > > The prime benefit of having dedicated classes over your approach is > > having syntactically ensured that you are indeed working with > > GZipped buffers. Personally I like that, but this is of course 100% > > subjective. > > Well, sure, but otherwise you can end up with classes for gzip, > bzip2, zip, 7zip, rar, etc. That alone is 10 extra classes, and I'm > sure there are other compression schemes people might want classes > for. That sounds messy to me. > > Having a constructor for a generic class that takes a parameter for > the compression type would give you what you want, assuming it's set > up so it returns an error if the content you pass it doesn't appear > to be of the selected type. > > I guess it doesn't really matter either way. You could even > implement GCompressedInputStream as a sort of class cluster that > returns a (private) subclass depending on the compression type, or > have all (public) classes be a subclass of a > GCompressed{In,Out}putStream class, and for all operations (except > for construction) you'd call methods on the superclass. > > And I think there's a benefit to support format auto-detection if the > developer doesn't care what format the input is in. That's possibly > a little more difficult to do with explicit subclasses, though the > class-cluster method would still work and yet maintain separate > classes for each compression format. I like the idea of a generic class and only supplying a MIME type, so that different compression implementations can go in a separate package just like GVfs backends today. It makes me think of gzip.GzipFile in Python which I like because it lets you use a compressed file just like a plain file, albeit I miss the autodetection there, so I second having that feature in GCompressedInputStream. Just my 2 cents, Christian _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list