>> As for the opening/closing the file stream issue, I guess >> a safe compromise would be to give the user the choice of >> whether the stream is perpetually open until explicitly >> closed, or if it's closed automatically after reading the >> data. Again, it depends on how the user uses the parser >> class. > > I think what we've got going now essentially does this - the > filetype parsers will leave the source "open" if it was open to > begin with (i.e. if a filehandle was passed) or close it if the > source is an unopened filename. > > We COULD add a "doNotCloseSource()" method (or some more intuitive > name :-) ) call and method for returning the still-open filehandle > to the caller, but I don't know if it'll be worth the extra complexity. > Thoughts? > Nahh, I don't like unnecessary added complexity. Who is going to want a file pointer that is at the end of the file and that was opened within some obscure library code to remain open afterwards? Just let the application re-open the stream. Keep things simple and intuitive.... Let's stick to the plan. Nico