On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru <nitin.mahendr...@gmail.com
> wrote:
> 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)
>
Interesting idea!
But I think I like the idea of a subclass better if we are going to split
the behavior b/w mutable and immutable.
For my money and the KISS principle, I would just add the put method in
CSVRecord.
Gary
>
> -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
> >
> >
>
