commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [CSV][POLL] How to provide mutable records
Date Fri, 25 Aug 2017 18:12:25 GMT
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.heger@oliver-heger.de>
wrote:

>
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message