Emmanuel, yes. Both the CVSParser and Iterator are two distinct designs. Both are types of parsers here. So it's really a question of design. Do you want your users to use the parser directly or work through the iterator or both? But they shouldn't interfere with each other.
Example: CVSParser p = record.parser(); Iterator i = record.iterator(); In the second example, Iterator is probably hiding the CVSParser underneath. This render's the original question moot. You can have as many concurrent parsers as you want with proper encapsulation. Paul On Wed, Aug 14, 2013 at 4:05 PM, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 14/08/2013 20:22, Benedikt Ritter a écrit : > >> Thanks for the input. Now is the time to talk about this kind of stuff. >> I understand Matt's proposal and it should be relatively easy to >> implement. >> >> However I see Paul's point but don't know yet how to develop the API the >> way he suggests. >> Paul can your point be summed up as: Either expose an iterator or a parser >> but not both? >> >> What do others think? Sebb? Gary? Emmanuel? >> This seems like one of the last issues on the road to 1.0 >> > > Throwing an IllegalArgumentException if iterator() is called more than > once would make sense. > > Following Paul's idea, we could probably hide the parser completely and > make it package private. The main entry point of the API would be > CSVFormat.parse(Reader) returning an Iterable<CSVRecord>. > > The public methods of CSVParser aren't that useful: > > * close()/isClosed() : resource management can be done outside [csv] > > * getCurrentLineNumber() : to be moved into CSVRecord? > > * getHeaderMap() : removed or moved into CSVRecord? > > * getRecordNumber() : already available in CSVRecord > > * getRecords() : to be removed. I guess [collections] or [lang] already > has a method turning an Iterable into a List? > > > Emmanuel Bourg > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Paul
