Am 21.08.2017 um 23:29 schrieb sebb: > 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.
Since Java 8 functional concepts and immutable data structures become more and more popular. It feels a bit strange to me going the opposite route. So my preference would also go towards [4]. The main use case was ETL, correct? We could check how such an approach would look like in such a scenario and maybe even add more support, e.g. implement a transformation loop that allows configuring a transformation function. Oliver > >> Gary > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
