Closed rhaist closed 9 years ago
Im not inclined to change the name. I tried to keep the api the same as in archive/tar and archive/zip. (though now that I look at it again I probably should have a ReadCloser returned by OpenReader).
Im not sure why you need to export that io.Reader, the main Reader is an io.Reader. All exporting that does is provide an io.Reader that doesn't do file checksum calculations.
I think following the same concepts as the archive/zip module would be a good way to go.
A ReadCloser is a good idea and would blend into other already existing decompression routines for the standard libraries.
Another conceptual change would be an iteratable File structure like archive/zip to be able to do something like: http://golang.org/pkg/archive/zip/#example_Reader
At the moment I have to use a for{ } construct with a hard coded break on io.EOF to tell if there are more files to read via Reader.Next()
Zip has a record containing the list of files at the end of the archive. When I first looked at it in rar it seemed optional and a bit more complicated, so I decided just to stick with the basics first (as the only docs are the unrar c++ source which I had enough trouble trying to understand). I'd have to look into it more to see how hard it would be.
I would like to propose to change the name of the "Reader" struct to "RarChild" to be more specific about its pupose. Also I propose to export the io.Reader for the RarChild objects to blend in with existing go archive decompression routines.