Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gilles 

On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru 


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
> > 
> > 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 ...
> >> replace) {
> >> // ...
> >> }
> >>
> >>
> >> Gilles
> >>
> >>
> >>
> >>> Gary
> >>>
> >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 
> >>> 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
>  :
>  >
>  > Feel free to provide a PR on GitHub :-)
>  >
>  > Gary
>  >
>  > On Aug 14, 2017 15:29, "Gary Gregory" 


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

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gary Gregory 
On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru  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 
> 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
> > > 
> > > 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 ...
> > >> replace) {
> > >> // ...
> > >> }
> > >>
> > >>
> > >> Gilles
> > >>
> > >>
> > >>
> > >>> Gary
> > >>>
> > >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 
> > >>> 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
> >  :
> >  >
> >  > Feel free to provide a PR on GitHub :-)
> >  >
> >  > Gary
> >  >
> >  > On Aug 14, 2017 15:29, "Gary Gregory" 
> >  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
> >   >  >
> >  >>> 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
>

Re: [CSV] CSVMutableRecord

2017-08-15 Thread nitin mahendru 
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  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
> > 
> > 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 ...
> >> replace) {
> >> // ...
> >> }
> >>
> >>
> >> Gilles
> >>
> >>
> >>
> >>> Gary
> >>>
> >>> On Aug 15, 2017 00:17, "Benedikt Ritter" 
> >>> 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
>  :
>  >
>  > Feel free to provide a PR on GitHub :-)
>  >
>  > Gary
>  >
>  > On Aug 14, 2017 15:29, "Gary Gregory" 
>  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
>    >
>  >>> 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
>
>

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gilles 

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 


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 ... 
replace) {

// ...
}


Gilles




Gary

On Aug 15, 2017 00:17, "Benedikt Ritter"  
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 
:

>
> Feel free to provide a PR on GitHub :-)
>
> Gary
>
> On Aug 14, 2017 15:29, "Gary Gregory"  
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 

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

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gary Gregory 
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.

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.

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.

Thoughts?

Gary

On Tue, Aug 15, 2017 at 8:33 AM, Gilles 
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 ... replace) {
> // ...
> }
>
>
> Gilles
>
>
>
>> Gary
>>
>> On Aug 15, 2017 00:17, "Benedikt Ritter"  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 :
>>> >
>>> > Feel free to provide a PR on GitHub :-)
>>> >
>>> > Gary
>>> >
>>> > On Aug 14, 2017 15:29, "Gary Gregory"  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 >> >
>>> >>> 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
>
>

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gilles 

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 ... replace) 
{

// ...
}


Gilles



Gary

On Aug 15, 2017 00:17, "Benedikt Ritter"  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 
:

>
> Feel free to provide a PR on GitHub :-)
>
> Gary
>
> On Aug 14, 2017 15:29, "Gary Gregory"  
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 


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

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Gary Gregory 
How does that work when you want to change more than one value?

Gary

On Aug 15, 2017 00:17, "Benedikt Ritter"  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 :
> >
> > Feel free to provide a PR on GitHub :-)
> >
> > Gary
> >
> > On Aug 14, 2017 15:29, "Gary Gregory"  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 
> >>> 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
>
>

Re: [CSV] CSVMutableRecord

2017-08-15 Thread Benedikt Ritter 
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 :
> 
> Feel free to provide a PR on GitHub :-)
> 
> Gary
> 
> On Aug 14, 2017 15:29, "Gary Gregory"  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 
>>> 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