How about having a state in the class itself which says that it's mutable
or not.
If we call a setter on an immutable then it throws an exception.
By default the records are immutable and you need to make them mutable
using a new API.
pros: Saves memory, Keeps the immutability benefits
cons: people using "mutable" records need to be careful.(While threading
maybe)

-Nitin




On Tue, Aug 15, 2017 at 9:01 AM Gilles <gil...@harfang.homelinux.org> wrote:

> On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
> > That looks odd to me. What comes up for me is the use case where I
> > want to
> > ETL a file of 10,000,000 records and update, say, one column. If am
> > forced
> > to create a brand new record for every record read, that would be a
> > shame.
>
> Why?
>
> > If I had a mutable record, I could just keep on updating it and using
> > it to
> > write each row. Read record, update it, write record. No extra memory
> > needed.
>
> How is the size of 1 additional record going to matter compared to the
> size of the whole program?
>
> > Either we can make the current record mutable (what's the harm?) or
> > we can
> > make the parser serve out mutable records based on a config setting.
> > This
> > could be a subclass of CSVRecord with the extra method I proposed.
>
> The harm is that you loose all the promises of immutability.
>
> Regards,
> Gilles
>
> >
> > Thoughts?
> >
> > Gary
> >
> > On Tue, Aug 15, 2017 at 8:33 AM, Gilles
> > <gil...@harfang.homelinux.org>
> > wrote:
> >
> >> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote:
> >>
> >>> How does that work when you want to change more than one value?
> >>>
> >>
> >> How about a "vararg" argument:
> >>
> >> /**
> >>  * @param orig Original to be copied.
> >>  * @param replace Fields to be replaced.
> >>  */
> >> public static CSVRecord createRecord(CSVRecord orig,
> >>                                      Pair<Integer, String> ...
> >> replace) {
> >>     // ...
> >> }
> >>
> >>
> >> Gilles
> >>
> >>
> >>
> >>> Gary
> >>>
> >>> On Aug 15, 2017 00:17, "Benedikt Ritter" <brit...@apache.org>
> >>> wrote:
> >>>
> >>> Hi,
> >>>>
> >>>> I very much like that CSVRecord is unmodifiable. So I’d suggest an
> >>>> API,
> >>>> that creates a new record instead of mutating the existing one:
> >>>>
> >>>> CSVRecord newRecord = myRecord.put(1, „value")
> >>>>
> >>>> I’m not sure about „put“ as a method name since it clashes with
> >>>> java.util.Map#put, which is mutation based...
> >>>>
> >>>> Regards,
> >>>> Benedikt
> >>>>
> >>>> > Am 15.08.2017 um 02:54 schrieb Gary Gregory
> >>>> <garydgreg...@gmail.com>:
> >>>> >
> >>>> > Feel free to provide a PR on GitHub :-)
> >>>> >
> >>>> > Gary
> >>>> >
> >>>> > On Aug 14, 2017 15:29, "Gary Gregory" <garydgreg...@gmail.com>
> >>>> wrote:
> >>>> >
> >>>> >> I think we've kept the design as YAGNI as possible... :-)
> >>>> >>
> >>>> >> Gary
> >>>> >>
> >>>> >> On Mon, Aug 14, 2017 at 3:25 PM, nitin mahendru <
> >>>> >> nitin.mahendr...@gmail.com> wrote:
> >>>> >>
> >>>> >>> Yeah that also is OK. I though there is a reason to keep the
> >>>> CSVRecord
> >>>> >>> without setters. But maybe not!
> >>>> >>>
> >>>> >>> Nitin
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>> On Mon, Aug 14, 2017 at 2:22 PM Gary Gregory
> >>>> <garydgreg...@gmail.com
> >>>> >
> >>>> >>> wrote:
> >>>> >>>
> >>>> >>>> Hi All:
> >>>> >>>>
> >>>> >>>> Should we consider adding put(int,Object) and put(String,
> >>>> Object) to
> >>>> the
> >>>> >>>> current CSVRecord class?
> >>>> >>>>
> >>>> >>>> Gary
> >>>> >>>>
> >>>> >>>> On Mon, Aug 14, 2017 at 2:54 PM, nitin mahendru <
> >>>> >>>> nitin.mahendr...@gmail.com>
> >>>> >>>> wrote:
> >>>> >>>>
> >>>> >>>>> Hi Everyone,
> >>>> >>>>>
> >>>> >>>>> I recently pushed a change(pull request 20) to get the line
> >>>> ending
> >>>> >>> from
> >>>> >>>> the
> >>>> >>>>> parser.
> >>>> >>>>>
> >>>> >>>>> Now I want to push another change which I feel will also be
> >>>> useful
> >>>> for
> >>>> >>>> the
> >>>> >>>>> community. I want to add a CSVRecordMutable class which had
> >>>> a
> >>>> >>> constructor
> >>>> >>>>> which accepts a CSVRecord object. So when we have a
> >>>> CSVRecordMutable
> >>>> >>>> object
> >>>> >>>>> from it then we can edit individual columns using it.
> >>>> >>>>>
> >>>> >>>>> I would be using this to write back my edited CSV file. My
> >>>> use case
> >>>> >>> is to
> >>>> >>>>> read a csv, mangle some columns, write back a new csv.
> >>>> >>>>>
> >>>> >>>>> I could have directly raised a pull request but I just
> >>>> wanted to
> >>>> float
> >>>> >>>> the
> >>>> >>>>> idea before and see the reaction.
> >>>> >>>>>
> >>>> >>>>> Thanks
> >>>> >>>>>
> >>>> >>>>> Nitin
> >>>> >>>>>
> >>>> >>>>
> >>>> >>>
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> >>>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Reply via email to