commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [CSV][POLL] How to provide mutable records
Date Tue, 22 Aug 2017 19:27:59 GMT


Am 21.08.2017 um 23:29 schrieb sebb:
> On 21 August 2017 at 21:04, Gary Gregory <garydgregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message