On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> 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.
A code example would be useful...
>> pros: Saves memory, Keeps the immutability benefits
What kind of usage are you considering that a single transient
record matters (as compared to the ~300 MB of the JVM itself...)?
>> 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.
Once you have a subclass that is able to modify the state of
its parent, it's a mutable object. Period.
There is no such thing as a "split".
>
> For my money and the KISS principle, I would just add the put
method
> in
> CSVRecord.
Then, any use that assumes immutability will be broken.
Gilles
> 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
