I really do not like [4], I personally would never want to use such an odd
looking API with arrays that I have to build as input.
What this super simple "solution", #5: Add a new toArray() method to
CSVRecord:
/**
* Clones a new array.
*
* @return a new array
*/
public String[] toArray() {
return values.clone();
}
You can edit the array as you wish and feed it to a CSVPrinter.
We can still kibitz with the proposed solution but toArray() gives a
lighter weight solution.
Gary
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.
>
> 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
>
>
