commons-csv
commons-csv copied to clipboard
apache
CSV-215 CSV Record mutability
I want to push another change which I feel will also be useful for the community. I want to add a CSVRecordMutable class which had a constructor which accepts a CSVRecord object. So when we have a CSVRecordMutable object from it then we can edit individual columns using it. I would be using this to write back my edited CSV file. My use case is to read a csv, mangle some columns, write back a new csv.
Coverage decreased (-0.2%) to 94.219% when pulling 0d54fa09857cc0a3e3627789c0d486ed215712e0 on nmahendru:master into 299fdccfd67319a0231efe82eba424003afb371d on apache:master.
Coverage decreased (-0.2%) to 94.242% when pulling cbfee0a38196beef7c9cab239eae746000866a6b on nmahendru:master into 299fdccfd67319a0231efe82eba424003afb371d on apache:master.
I do not like the mutability toggle. Our options, I think are:
- add CSVRecord.put(int, Object)
- add CSVRecord.put(String, Object)
and document that the CSVRecord class is now mutable. This is the simplest solution.
Alternatively, if we are hard core about maintaining CSVRecord as immutable, we can talk about that.
BUT, note that the fact that the current implementation is immutable is NOT documented, all we say in the CSVRecord Javadoc is: "A CSV record parsed from a CSV file."
The toggle was just an option to keep immutability in some sense. But Making it mutable and documenting it looks better. Wan't another pull request ?
Up to you. I do not think we've reached any kind of consensus on the dev ML though.
Personally I don't like the "mutability" toggle and would prefer to have a setter - basically I see two options to implement the setter
- an immutable setter returning a new CSVRecord
- a mutable setter which modifies the object
See also #25 instead. The withValue() setters does like @sgoeschl suggest and either return a new CSVRecord or mutates the current object. mutable() or immutable() or a CVFormat flag can be used to force either variant for efficiency reasons.
