On 21 August 2017 at 21:04, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All, > > We have a request for [CSV] to provide mutable records. There is no clear > consensus to me on how to do this. The current CSVRecord class is immutable > but is not documented as such. I attribute that to YAGNI up to now. > > Options range from simply making CSVRecord immutable to creating a new > CSVMutableRecord class and a few things in between. > > I'd like to get a feel what the community thinks here. IMO this boils down > to whether or not it matters that CSVRecord remains immutable. > > [0] do nothing > > [1] Add two put methods to CVSRecord making the class mutable: > put(int,Object) and put(String,Object). This does not break BC but changes > the runtime behavior for apps that expect immutable record and shard the > records with other components. > > [2] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such > that a new boolean in CVSRecord allow method from 1) above to either work > or throw an exception. > > [3] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such > that subclass of CVSRecord called CVSMutableRecord is created which > contains two new put methods. See branch CSV-216. > > [4] The factory method: > /** > * @param orig Original to be copied. > * @param replace Fields to be replaced. > * @return a copy of "orig", except for the fields in "replace". > */ > public static CSVRecord createRecord(CSVRecord orig, > Pair<Integer, String> ... replace) > > Could also be: > public static CSVRecord createRecord(CSVRecord orig, > int[] replaceIndices, > String[] replaceValues) > > I like the simplicity of [1] and I coded [3] to see how cumbersome that > feels. > > So my preference is [1].
What about [4]? Would that be more complicated/cumbersome to use than [1]? Seems to me using a factory or builder to create an updated immutable copy is the way to go here. > Gary --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
