CSV-215 CSV Record mutability

[nmahendru]

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.

[coveralls]

Coverage decreased (-0.2%) to 94.219% when pulling 0d54fa0 on nmahendru:master into 299fdcc on apache:master.

[coveralls]

Coverage decreased (-0.2%) to 94.242% when pulling cbfee0a on nmahendru:master into 299fdcc on apache:master.

[garydgregory]

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."

[nmahendru]

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 ?

[garydgregory]

Up to you. I do not think we've reached any kind of consensus on the dev ML though.

[nmahendru]

I'll wait then.

[sgoeschl]

Personally I don't like the "mutability" toggle and would prefer to have a setter - basically I see two options to implement the setter

1. an immutable setter returning a new CSVRecord
2. a mutable setter which modifies the object

[stain]

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.