On Tue, Aug 22, 2017 at 1:27 PM, Oliver Heger <oliver.he...@oliver-heger.de> wrote:
> > > 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. > The use case is, IMO, _lightweight_ ETL; for anything serious I would use Spring Batch. This is why I favor the simplest solution. Gary > > 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 > >
