It might help to step back from the story and look at it from the
perspective of a Commons CSV user who is familiar with using Maps.
How should a Map derived from a CSVRecord behave?
What happens with the put() and putAll() methods?
What happens when get() and put() are called with invalid keys?
Is the CSVRecord-derived Map going to behave differently than any other
Map in a significant way? If yes, do we really want to do that?
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/21/2014 8:04 AM, Gary Gregory wrote:
My story: There should be some kind of play between a CSVRecord and a
Map<String, String>.
My current app requires only reading, not writing.
Solutions:
- CSVRecord implements Map<String, String>
- CSVRecord implements Map<String, String> but read-only
- CSVRecord implements toMap() -> Map<String, String> (a plain HashMap)
- CSVRecord implements toMap() -> Map<String, String> (a read-only HashMap)
- Split CSVRecord into a CSVMappedRecord subclass which can implement one
of the above.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
