commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: [CSV][POLL] How to provide mutable records
Date Fri, 25 Aug 2017 18:19:58 GMT
This came up also for commons rdf where we also have everything immutable,
which I think is a good principle to keep for modern Java 8 programming.

So you need a mutator function like in (4) that either returns a new
immutable (but changed) CSVRecord; or alternatively a different
MutableCSVRecord that can then be built/frozen to a CSVRecord. (These can
then share a common accessor interface for the passive functions)

Is there likely to be many changes to each CSVRecord or just one on each?

On 25 Aug 2017 7:05 pm, "Gary Gregory" <garydgregory@gmail.com> wrote:

On Mon, Aug 21, 2017 at 3:29 PM, sebb <sebbaz@gmail.com> wrote:

> 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.
>

You mean a "mutable" copy right? Because the records are currently
immutable.

Gary


>
> > Gary
>
> ---------------------------------------------------------------------
> 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