You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by nitin mahendru <ni...@gmail.com> on 2017/08/14 20:54:20 UTC
[CSV] CSVMutableRecord
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
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 18, 2017 at 11:52 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 18 Aug 2017 11:34:54 -0600, Gary Gregory wrote:
>
>> To be clear, you are then OK with simply adding the two put() methods to
>> CSVRecord? Option 1 in my eariler message.
>>
>
> Actually, I think that it is not OK to not acknowledge the
> breaking nature of the proposal.
> As Simon noted you might want to consider that such a change
> warrants a major release, or not if you _decide_ that the
> project never promised immutability (despite what the source
> says through self-documentation).
>
> I'm not opposing a decision to break, if that's your preferred
> option (despite the technical arguments against what I proposed
> have not been substantiated IIUC).
>
> In any cases, a mutable subclass is not a solution IMO.
>
> Not sure I'm clear enough... :-)
hm, so add the 2 put APIs and call it 2.0. That's fine with me.
Gary
>
> Gilles
>
>
> Gary
>>
>> On Fri, Aug 18, 2017 at 10:05 AM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
>>>
>>> Please see branch CSV-216 for a KISS implementation that uses a
>>>> CSVMutableRecord subclass.
>>>>
>>>>
>>> I don't think anyone gains anything through this subclassing.
>>>
>>> A client can no longer assume that an instance of "CSVRecord" is
>>> immutable and will have to make a defensive copy or an "instanceof"
>>> check (that will be obsolete/broken whenever the hierarchy is
>>> modified).
>>>
>>> Better assume a functionally breaking change and add the methods
>>> to class "CSVRecord"...
>>>
>>> Gilles
>>>
>>>
>>>
>>> I do not believe this feature warrants creating interfaces or
>>>> framework-like code. I do not believe we need to start leaning the
>>>> JDBC-way.
>>>>
>>>> Gary
>>>>
>>>> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com>
>>>> wrote:
>>>>
>>>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>>>
>>>>>
>>>>> Saying that making record mutable is "breaking" is a bit unfair when we
>>>>> do
>>>>> > NOT document the mutability of the class in the first place.
>>>>> >
>>>>>
>>>>> I'm stating a fact: class is currently immutable, change would make it
>>>>> mutable; it is functionally breaking.
>>>>> I didn't say that you are forbidden to do it; just that it would be
>>>>> unwise,
>>>>> particularly if it would be to save a few bytes.
>>>>>
>>>>>
>>>>> Exactly.
>>>>>
>>>>> TL;DR. This is almost always a breaking semantic change; the safest
>>>>> ways
>>>>> of implementing it are binary breaking; it's unlikely to have a major
>>>>> performance impact; it might be better to create a new API module for
>>>>> enhancements, with current package as legacy or implementation.
>>>>>
>>>>> If a class previously exposed no mutators, adding one is usually a
>>>>> major
>>>>> change. This is especially true for final classes, but it still affects
>>>>> use
>>>>> cases where an instance is owned by another class, which may rely on
>>>>> the
>>>>> lack of mutability to avoid making defensive copies.
>>>>> Of course, a final class that has a package-private getter to a
>>>>> shared
>>>>> copy of its backing array could be considered to be sending mixed
>>>>> messages...
>>>>>
>>>>> It is possible that a mutable class might have significant performance
>>>>> advantages over an immutable one beyond saving a few bytes. For
>>>>> example,
>>>>> if
>>>>> the updates are simple, and depend on the previous value of the cell,
>>>>> then
>>>>> a mutable version might have better cache behavior. If there's other
>>>>> sources of cache pressure this might have a higher than expected
>>>>> impact.
>>>>> The costs of copying the original values might also be relatively
>>>>> significant.
>>>>>
>>>>> For an ETL use case these issues are unlikely to be limiting factors;
>>>>> for a
>>>>> start, there's a non-zero chance that a CSVRecord was extracted by
>>>>> parsing a CSV file. Also a transform will require conversion to some
>>>>> sort
>>>>> of Number (or String allocation).
>>>>>
>>>>> The current API doesn't easily support adding alternate implementations
>>>>> of
>>>>> the relevant types. Implementation classes are final, and important
>>>>> return
>>>>> types are concrete.
>>>>>
>>>>> One solution might be to treat the current code as almost an
>>>>> implementation
>>>>> module, define a separate API module, and add extra interfaces and
>>>>> alternate implementations to support the target use case (mutable
>>>>> records, streams, reactivex, transform functions or what have you).
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 18, 2017 at 12:41 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 18 Aug 2017 19:52:01 +0200, Gilles wrote:
>
>> On Fri, 18 Aug 2017 11:34:54 -0600, Gary Gregory wrote:
>>
>>> To be clear, you are then OK with simply adding the two put() methods to
>>> CSVRecord? Option 1 in my eariler message.
>>>
>>
>> Actually, I think that it is not OK to not acknowledge the
>> breaking nature of the proposal.
>> As Simon noted you might want to consider that such a change
>> warrants a major release, or not if you _decide_ that the
>> project never promised immutability (despite what the source
>> says through self-documentation).
>>
>> I'm not opposing a decision to break, if that's your preferred
>> option (despite the technical arguments against what I proposed
>> have not been substantiated IIUC).
>>
>
> By the above paragraph I mean that I don't remember reading why
> the following (pseudo-code) was not a good option:
> ---CUT---
> CSRecord rec = readRecord(source);
> rec = rec.copyAndReplace(new int[] {1, 4},
> new String[] {"Change", "this"});
> ---CUT---
>
The above is non-intuitive, this is clear and simple
rec.put(1, "Change");
rec.put(4, "this");
Gary
> Gilles
>
>
>
>> In any cases, a mutable subclass is not a solution IMO.
>>
>> Not sure I'm clear enough... :-)
>> Gilles
>>
>> Gary
>>>
>>> On Fri, Aug 18, 2017 at 10:05 AM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
>>>>
>>>> Please see branch CSV-216 for a KISS implementation that uses a
>>>>> CSVMutableRecord subclass.
>>>>>
>>>>>
>>>> I don't think anyone gains anything through this subclassing.
>>>>
>>>> A client can no longer assume that an instance of "CSVRecord" is
>>>> immutable and will have to make a defensive copy or an "instanceof"
>>>> check (that will be obsolete/broken whenever the hierarchy is
>>>> modified).
>>>>
>>>> Better assume a functionally breaking change and add the methods
>>>> to class "CSVRecord"...
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>> I do not believe this feature warrants creating interfaces or
>>>>> framework-like code. I do not believe we need to start leaning the
>>>>> JDBC-way.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Saying that making record mutable is "breaking" is a bit unfair when
>>>>>> we
>>>>>> do
>>>>>> > NOT document the mutability of the class in the first place.
>>>>>> >
>>>>>>
>>>>>> I'm stating a fact: class is currently immutable, change would make it
>>>>>> mutable; it is functionally breaking.
>>>>>> I didn't say that you are forbidden to do it; just that it would be
>>>>>> unwise,
>>>>>> particularly if it would be to save a few bytes.
>>>>>>
>>>>>>
>>>>>> Exactly.
>>>>>>
>>>>>> TL;DR. This is almost always a breaking semantic change; the safest
>>>>>> ways
>>>>>> of implementing it are binary breaking; it's unlikely to have a major
>>>>>> performance impact; it might be better to create a new API module for
>>>>>> enhancements, with current package as legacy or implementation.
>>>>>>
>>>>>> If a class previously exposed no mutators, adding one is usually a
>>>>>> major
>>>>>> change. This is especially true for final classes, but it still
>>>>>> affects
>>>>>> use
>>>>>> cases where an instance is owned by another class, which may rely on
>>>>>> the
>>>>>> lack of mutability to avoid making defensive copies.
>>>>>> Of course, a final class that has a package-private getter to a
>>>>>> shared
>>>>>> copy of its backing array could be considered to be sending mixed
>>>>>> messages...
>>>>>>
>>>>>> It is possible that a mutable class might have significant performance
>>>>>> advantages over an immutable one beyond saving a few bytes. For
>>>>>> example,
>>>>>> if
>>>>>> the updates are simple, and depend on the previous value of the cell,
>>>>>> then
>>>>>> a mutable version might have better cache behavior. If there's other
>>>>>> sources of cache pressure this might have a higher than expected
>>>>>> impact.
>>>>>> The costs of copying the original values might also be relatively
>>>>>> significant.
>>>>>>
>>>>>> For an ETL use case these issues are unlikely to be limiting factors;
>>>>>> for a
>>>>>> start, there's a non-zero chance that a CSVRecord was extracted by
>>>>>> parsing a CSV file. Also a transform will require conversion to some
>>>>>> sort
>>>>>> of Number (or String allocation).
>>>>>>
>>>>>> The current API doesn't easily support adding alternate
>>>>>> implementations
>>>>>> of
>>>>>> the relevant types. Implementation classes are final, and important
>>>>>> return
>>>>>> types are concrete.
>>>>>>
>>>>>> One solution might be to treat the current code as almost an
>>>>>> implementation
>>>>>> module, define a separate API module, and add extra interfaces and
>>>>>> alternate implementations to support the target use case (mutable
>>>>>> records, streams, reactivex, transform functions or what have you).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 19:52:01 +0200, Gilles wrote:
> On Fri, 18 Aug 2017 11:34:54 -0600, Gary Gregory wrote:
>> To be clear, you are then OK with simply adding the two put()
>> methods to
>> CSVRecord? Option 1 in my eariler message.
>
> Actually, I think that it is not OK to not acknowledge the
> breaking nature of the proposal.
> As Simon noted you might want to consider that such a change
> warrants a major release, or not if you _decide_ that the
> project never promised immutability (despite what the source
> says through self-documentation).
>
> I'm not opposing a decision to break, if that's your preferred
> option (despite the technical arguments against what I proposed
> have not been substantiated IIUC).
By the above paragraph I mean that I don't remember reading why
the following (pseudo-code) was not a good option:
---CUT---
CSRecord rec = readRecord(source);
rec = rec.copyAndReplace(new int[] {1, 4},
new String[] {"Change", "this"});
---CUT---
Gilles
>
> In any cases, a mutable subclass is not a solution IMO.
>
> Not sure I'm clear enough... :-)
> Gilles
>
>> Gary
>>
>> On Fri, Aug 18, 2017 at 10:05 AM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
>>>
>>>> Please see branch CSV-216 for a KISS implementation that uses a
>>>> CSVMutableRecord subclass.
>>>>
>>>
>>> I don't think anyone gains anything through this subclassing.
>>>
>>> A client can no longer assume that an instance of "CSVRecord" is
>>> immutable and will have to make a defensive copy or an "instanceof"
>>> check (that will be obsolete/broken whenever the hierarchy is
>>> modified).
>>>
>>> Better assume a functionally breaking change and add the methods
>>> to class "CSVRecord"...
>>>
>>> Gilles
>>>
>>>
>>>
>>>> I do not believe this feature warrants creating interfaces or
>>>> framework-like code. I do not believe we need to start leaning the
>>>> JDBC-way.
>>>>
>>>> Gary
>>>>
>>>> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com>
>>>> wrote:
>>>>
>>>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>>
>>>>> Saying that making record mutable is "breaking" is a bit unfair
>>>>> when we
>>>>> do
>>>>> > NOT document the mutability of the class in the first place.
>>>>> >
>>>>>
>>>>> I'm stating a fact: class is currently immutable, change would
>>>>> make it
>>>>> mutable; it is functionally breaking.
>>>>> I didn't say that you are forbidden to do it; just that it would
>>>>> be
>>>>> unwise,
>>>>> particularly if it would be to save a few bytes.
>>>>>
>>>>>
>>>>> Exactly.
>>>>>
>>>>> TL;DR. This is almost always a breaking semantic change; the
>>>>> safest ways
>>>>> of implementing it are binary breaking; it's unlikely to have a
>>>>> major
>>>>> performance impact; it might be better to create a new API module
>>>>> for
>>>>> enhancements, with current package as legacy or implementation.
>>>>>
>>>>> If a class previously exposed no mutators, adding one is usually
>>>>> a major
>>>>> change. This is especially true for final classes, but it still
>>>>> affects
>>>>> use
>>>>> cases where an instance is owned by another class, which may rely
>>>>> on the
>>>>> lack of mutability to avoid making defensive copies.
>>>>> Of course, a final class that has a package-private getter to a
>>>>> shared
>>>>> copy of its backing array could be considered to be sending mixed
>>>>> messages...
>>>>>
>>>>> It is possible that a mutable class might have significant
>>>>> performance
>>>>> advantages over an immutable one beyond saving a few bytes. For
>>>>> example,
>>>>> if
>>>>> the updates are simple, and depend on the previous value of the
>>>>> cell,
>>>>> then
>>>>> a mutable version might have better cache behavior. If there's
>>>>> other
>>>>> sources of cache pressure this might have a higher than expected
>>>>> impact.
>>>>> The costs of copying the original values might also be relatively
>>>>> significant.
>>>>>
>>>>> For an ETL use case these issues are unlikely to be limiting
>>>>> factors;
>>>>> for a
>>>>> start, there's a non-zero chance that a CSVRecord was extracted
>>>>> by
>>>>> parsing a CSV file. Also a transform will require conversion to
>>>>> some sort
>>>>> of Number (or String allocation).
>>>>>
>>>>> The current API doesn't easily support adding alternate
>>>>> implementations
>>>>> of
>>>>> the relevant types. Implementation classes are final, and
>>>>> important
>>>>> return
>>>>> types are concrete.
>>>>>
>>>>> One solution might be to treat the current code as almost an
>>>>> implementation
>>>>> module, define a separate API module, and add extra interfaces
>>>>> and
>>>>> alternate implementations to support the target use case
>>>>> (mutable
>>>>> records, streams, reactivex, transform functions or what have
>>>>> you).
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 11:34:54 -0600, Gary Gregory wrote:
> To be clear, you are then OK with simply adding the two put() methods
> to
> CSVRecord? Option 1 in my eariler message.
Actually, I think that it is not OK to not acknowledge the
breaking nature of the proposal.
As Simon noted you might want to consider that such a change
warrants a major release, or not if you _decide_ that the
project never promised immutability (despite what the source
says through self-documentation).
I'm not opposing a decision to break, if that's your preferred
option (despite the technical arguments against what I proposed
have not been substantiated IIUC).
In any cases, a mutable subclass is not a solution IMO.
Not sure I'm clear enough... :-)
Gilles
> Gary
>
> On Fri, Aug 18, 2017 at 10:05 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
>>
>>> Please see branch CSV-216 for a KISS implementation that uses a
>>> CSVMutableRecord subclass.
>>>
>>
>> I don't think anyone gains anything through this subclassing.
>>
>> A client can no longer assume that an instance of "CSVRecord" is
>> immutable and will have to make a defensive copy or an "instanceof"
>> check (that will be obsolete/broken whenever the hierarchy is
>> modified).
>>
>> Better assume a functionally breaking change and add the methods
>> to class "CSVRecord"...
>>
>> Gilles
>>
>>
>>
>>> I do not believe this feature warrants creating interfaces or
>>> framework-like code. I do not believe we need to start leaning the
>>> JDBC-way.
>>>
>>> Gary
>>>
>>> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com>
>>> wrote:
>>>
>>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org>
>>> wrote:
>>>>
>>>> Saying that making record mutable is "breaking" is a bit unfair
>>>> when we
>>>> do
>>>> > NOT document the mutability of the class in the first place.
>>>> >
>>>>
>>>> I'm stating a fact: class is currently immutable, change would
>>>> make it
>>>> mutable; it is functionally breaking.
>>>> I didn't say that you are forbidden to do it; just that it would
>>>> be
>>>> unwise,
>>>> particularly if it would be to save a few bytes.
>>>>
>>>>
>>>> Exactly.
>>>>
>>>> TL;DR. This is almost always a breaking semantic change; the
>>>> safest ways
>>>> of implementing it are binary breaking; it's unlikely to have a
>>>> major
>>>> performance impact; it might be better to create a new API module
>>>> for
>>>> enhancements, with current package as legacy or implementation.
>>>>
>>>> If a class previously exposed no mutators, adding one is usually a
>>>> major
>>>> change. This is especially true for final classes, but it still
>>>> affects
>>>> use
>>>> cases where an instance is owned by another class, which may rely
>>>> on the
>>>> lack of mutability to avoid making defensive copies.
>>>> Of course, a final class that has a package-private getter to a
>>>> shared
>>>> copy of its backing array could be considered to be sending mixed
>>>> messages...
>>>>
>>>> It is possible that a mutable class might have significant
>>>> performance
>>>> advantages over an immutable one beyond saving a few bytes. For
>>>> example,
>>>> if
>>>> the updates are simple, and depend on the previous value of the
>>>> cell,
>>>> then
>>>> a mutable version might have better cache behavior. If there's
>>>> other
>>>> sources of cache pressure this might have a higher than expected
>>>> impact.
>>>> The costs of copying the original values might also be relatively
>>>> significant.
>>>>
>>>> For an ETL use case these issues are unlikely to be limiting
>>>> factors;
>>>> for a
>>>> start, there's a non-zero chance that a CSVRecord was extracted
>>>> by
>>>> parsing a CSV file. Also a transform will require conversion to
>>>> some sort
>>>> of Number (or String allocation).
>>>>
>>>> The current API doesn't easily support adding alternate
>>>> implementations
>>>> of
>>>> the relevant types. Implementation classes are final, and
>>>> important
>>>> return
>>>> types are concrete.
>>>>
>>>> One solution might be to treat the current code as almost an
>>>> implementation
>>>> module, define a separate API module, and add extra interfaces and
>>>> alternate implementations to support the target use case
>>>> (mutable
>>>> records, streams, reactivex, transform functions or what have
>>>> you).
>>>>
>>>> Simon
>>>>
>>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
To be clear, you are then OK with simply adding the two put() methods to
CSVRecord? Option 1 in my eariler message.
Gary
On Fri, Aug 18, 2017 at 10:05 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
>
>> Please see branch CSV-216 for a KISS implementation that uses a
>> CSVMutableRecord subclass.
>>
>
> I don't think anyone gains anything through this subclassing.
>
> A client can no longer assume that an instance of "CSVRecord" is
> immutable and will have to make a defensive copy or an "instanceof"
> check (that will be obsolete/broken whenever the hierarchy is
> modified).
>
> Better assume a functionally breaking change and add the methods
> to class "CSVRecord"...
>
> Gilles
>
>
>
>> I do not believe this feature warrants creating interfaces or
>> framework-like code. I do not believe we need to start leaning the
>> JDBC-way.
>>
>> Gary
>>
>> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com> wrote:
>>
>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>>
>>> Saying that making record mutable is "breaking" is a bit unfair when we
>>> do
>>> > NOT document the mutability of the class in the first place.
>>> >
>>>
>>> I'm stating a fact: class is currently immutable, change would make it
>>> mutable; it is functionally breaking.
>>> I didn't say that you are forbidden to do it; just that it would be
>>> unwise,
>>> particularly if it would be to save a few bytes.
>>>
>>>
>>> Exactly.
>>>
>>> TL;DR. This is almost always a breaking semantic change; the safest ways
>>> of implementing it are binary breaking; it's unlikely to have a major
>>> performance impact; it might be better to create a new API module for
>>> enhancements, with current package as legacy or implementation.
>>>
>>> If a class previously exposed no mutators, adding one is usually a major
>>> change. This is especially true for final classes, but it still affects
>>> use
>>> cases where an instance is owned by another class, which may rely on the
>>> lack of mutability to avoid making defensive copies.
>>> Of course, a final class that has a package-private getter to a shared
>>> copy of its backing array could be considered to be sending mixed
>>> messages...
>>>
>>> It is possible that a mutable class might have significant performance
>>> advantages over an immutable one beyond saving a few bytes. For example,
>>> if
>>> the updates are simple, and depend on the previous value of the cell,
>>> then
>>> a mutable version might have better cache behavior. If there's other
>>> sources of cache pressure this might have a higher than expected impact.
>>> The costs of copying the original values might also be relatively
>>> significant.
>>>
>>> For an ETL use case these issues are unlikely to be limiting factors;
>>> for a
>>> start, there's a non-zero chance that a CSVRecord was extracted by
>>> parsing a CSV file. Also a transform will require conversion to some sort
>>> of Number (or String allocation).
>>>
>>> The current API doesn't easily support adding alternate implementations
>>> of
>>> the relevant types. Implementation classes are final, and important
>>> return
>>> types are concrete.
>>>
>>> One solution might be to treat the current code as almost an
>>> implementation
>>> module, define a separate API module, and add extra interfaces and
>>> alternate implementations to support the target use case (mutable
>>> records, streams, reactivex, transform functions or what have you).
>>>
>>> Simon
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote:
> Please see branch CSV-216 for a KISS implementation that uses a
> CSVMutableRecord subclass.
I don't think anyone gains anything through this subclassing.
A client can no longer assume that an instance of "CSVRecord" is
immutable and will have to make a defensive copy or an "instanceof"
check (that will be obsolete/broken whenever the hierarchy is
modified).
Better assume a functionally breaking change and add the methods
to class "CSVRecord"...
Gilles
>
> I do not believe this feature warrants creating interfaces or
> framework-like code. I do not believe we need to start leaning the
> JDBC-way.
>
> Gary
>
> On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com>
> wrote:
>
>> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org>
>> wrote:
>>
>> Saying that making record mutable is "breaking" is a bit unfair when
>> we do
>> > NOT document the mutability of the class in the first place.
>> >
>>
>> I'm stating a fact: class is currently immutable, change would make
>> it
>> mutable; it is functionally breaking.
>> I didn't say that you are forbidden to do it; just that it would be
>> unwise,
>> particularly if it would be to save a few bytes.
>>
>>
>> Exactly.
>>
>> TL;DR. This is almost always a breaking semantic change; the safest
>> ways
>> of implementing it are binary breaking; it's unlikely to have a
>> major
>> performance impact; it might be better to create a new API module
>> for
>> enhancements, with current package as legacy or implementation.
>>
>> If a class previously exposed no mutators, adding one is usually a
>> major
>> change. This is especially true for final classes, but it still
>> affects use
>> cases where an instance is owned by another class, which may rely on
>> the
>> lack of mutability to avoid making defensive copies.
>> Of course, a final class that has a package-private getter to a
>> shared
>> copy of its backing array could be considered to be sending mixed
>> messages...
>>
>> It is possible that a mutable class might have significant
>> performance
>> advantages over an immutable one beyond saving a few bytes. For
>> example, if
>> the updates are simple, and depend on the previous value of the
>> cell, then
>> a mutable version might have better cache behavior. If there's other
>> sources of cache pressure this might have a higher than expected
>> impact.
>> The costs of copying the original values might also be relatively
>> significant.
>>
>> For an ETL use case these issues are unlikely to be limiting
>> factors; for a
>> start, there's a non-zero chance that a CSVRecord was extracted by
>> parsing a CSV file. Also a transform will require conversion to some
>> sort
>> of Number (or String allocation).
>>
>> The current API doesn't easily support adding alternate
>> implementations of
>> the relevant types. Implementation classes are final, and important
>> return
>> types are concrete.
>>
>> One solution might be to treat the current code as almost an
>> implementation
>> module, define a separate API module, and add extra interfaces and
>> alternate implementations to support the target use case (mutable
>> records, streams, reactivex, transform functions or what have you).
>>
>> Simon
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
Please see branch CSV-216 for a KISS implementation that uses a
CSVMutableRecord subclass.
I do not believe this feature warrants creating interfaces or
framework-like code. I do not believe we need to start leaning the JDBC-way.
Gary
On Thu, Aug 17, 2017 at 3:04 PM, Simon Spero <se...@gmail.com> wrote:
> On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>
> Saying that making record mutable is "breaking" is a bit unfair when we do
> > NOT document the mutability of the class in the first place.
> >
>
> I'm stating a fact: class is currently immutable, change would make it
> mutable; it is functionally breaking.
> I didn't say that you are forbidden to do it; just that it would be unwise,
> particularly if it would be to save a few bytes.
>
>
> Exactly.
>
> TL;DR. This is almost always a breaking semantic change; the safest ways
> of implementing it are binary breaking; it's unlikely to have a major
> performance impact; it might be better to create a new API module for
> enhancements, with current package as legacy or implementation.
>
> If a class previously exposed no mutators, adding one is usually a major
> change. This is especially true for final classes, but it still affects use
> cases where an instance is owned by another class, which may rely on the
> lack of mutability to avoid making defensive copies.
> Of course, a final class that has a package-private getter to a shared
> copy of its backing array could be considered to be sending mixed
> messages...
>
> It is possible that a mutable class might have significant performance
> advantages over an immutable one beyond saving a few bytes. For example, if
> the updates are simple, and depend on the previous value of the cell, then
> a mutable version might have better cache behavior. If there's other
> sources of cache pressure this might have a higher than expected impact.
> The costs of copying the original values might also be relatively
> significant.
>
> For an ETL use case these issues are unlikely to be limiting factors; for a
> start, there's a non-zero chance that a CSVRecord was extracted by
> parsing a CSV file. Also a transform will require conversion to some sort
> of Number (or String allocation).
>
> The current API doesn't easily support adding alternate implementations of
> the relevant types. Implementation classes are final, and important return
> types are concrete.
>
> One solution might be to treat the current code as almost an implementation
> module, define a separate API module, and add extra interfaces and
> alternate implementations to support the target use case (mutable
> records, streams, reactivex, transform functions or what have you).
>
> Simon
>
Re: [CSV] CSVMutableRecord
Posted by Simon Spero <se...@gmail.com>.
On Aug 15, 2017 8:01 PM, "Gilles" <gi...@harfang.homelinux.org> wrote:
Saying that making record mutable is "breaking" is a bit unfair when we do
> NOT document the mutability of the class in the first place.
>
I'm stating a fact: class is currently immutable, change would make it
mutable; it is functionally breaking.
I didn't say that you are forbidden to do it; just that it would be unwise,
particularly if it would be to save a few bytes.
Exactly.
TL;DR. This is almost always a breaking semantic change; the safest ways
of implementing it are binary breaking; it's unlikely to have a major
performance impact; it might be better to create a new API module for
enhancements, with current package as legacy or implementation.
If a class previously exposed no mutators, adding one is usually a major
change. This is especially true for final classes, but it still affects use
cases where an instance is owned by another class, which may rely on the
lack of mutability to avoid making defensive copies.
Of course, a final class that has a package-private getter to a shared
copy of its backing array could be considered to be sending mixed
messages...
It is possible that a mutable class might have significant performance
advantages over an immutable one beyond saving a few bytes. For example, if
the updates are simple, and depend on the previous value of the cell, then
a mutable version might have better cache behavior. If there's other
sources of cache pressure this might have a higher than expected impact.
The costs of copying the original values might also be relatively
significant.
For an ETL use case these issues are unlikely to be limiting factors; for a
start, there's a non-zero chance that a CSVRecord was extracted by
parsing a CSV file. Also a transform will require conversion to some sort
of Number (or String allocation).
The current API doesn't easily support adding alternate implementations of
the relevant types. Implementation classes are final, and important return
types are concrete.
One solution might be to treat the current code as almost an implementation
module, define a separate API module, and add extra interfaces and
alternate implementations to support the target use case (mutable
records, streams, reactivex, transform functions or what have you).
Simon
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 25, 2017 at 11:08 AM, nitin mahendru <nitin.mahendru88@gmail.com
> wrote:
> Hi Everyone,
>
> Any decision on this yet ?
>
Not yet. Needs a bit more stewing and brewing...
Gary
> Thanks
>
> Nitin
>
>
>
>
> On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru <nitin.mahendru88@gmail.com
> >
> wrote:
>
> > Just another follow up. Anything new ?
> >
> > -Nitin
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >> Not yet ;-)
> >>
> >> On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com>
> >> wrote:
> >>
> >> > Hi All,
> >> >
> >> > Any consensus on this ?
> >> >
> >> > -Nitin
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
> >> > wrote:
> >> >
> >> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <
> gilles@harfang.homelinux.org
> >> >
> >> > > wrote:
> >> > >
> >> > > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> >> > > >
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>
> >> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>> <nitin.mahendru88@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...
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Below is the pull request I added.
> >> > > >> https://github.com/apache/commons-csv/pull/21
> >> > > >>
> >> > > >
> >> > > > As I indicated in the previous message, this is functionally
> >> > > > breaking. [I'm diverting this discussion over to the "dev"
> >> > > > mailing list.]
> >> > > >
> >> > >
> >> > > Saying that making record mutable is "breaking" is a bit unfair when
> >> we
> >> > do
> >> > > NOT document the mutability of the class in the first place.
> >> > >
> >> > > Gary
> >> > >
> >> > >
> >> > > >
> >> > > > The following should be an interesting read:
> >> > > > http://markmail.org/message/6ytvmxvy2ndsfp7h
> >> > > >
> >> > > >
> >> > > > Regards,
> >> > > > Gilles
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
> >> gilles@harfang.homelinux.org
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>> > <nitin.mahendru88@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
> >> > > >>> >> <gi...@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
> >> > > >>> >> > > <gi...@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" <
> >> > britter@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
> >> > > >>> >> > >>>> <ga...@gmail.com>:
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > Gary
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> >> > > >>> >> <ga...@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.mahendru88@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
> >> > > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> >> > > >>> For additional commands, e-mail: user-help@commons.apache.org
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >> > > > For additional commands, e-mail: user-help@commons.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 25, 2017 at 11:08 AM, nitin mahendru <nitin.mahendru88@gmail.com
> wrote:
> Hi Everyone,
>
> Any decision on this yet ?
>
Not yet. Needs a bit more stewing and brewing...
Gary
> Thanks
>
> Nitin
>
>
>
>
> On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru <nitin.mahendru88@gmail.com
> >
> wrote:
>
> > Just another follow up. Anything new ?
> >
> > -Nitin
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >> Not yet ;-)
> >>
> >> On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com>
> >> wrote:
> >>
> >> > Hi All,
> >> >
> >> > Any consensus on this ?
> >> >
> >> > -Nitin
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
> >> > wrote:
> >> >
> >> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <
> gilles@harfang.homelinux.org
> >> >
> >> > > wrote:
> >> > >
> >> > > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> >> > > >
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>
> >> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>> <nitin.mahendru88@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...
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Below is the pull request I added.
> >> > > >> https://github.com/apache/commons-csv/pull/21
> >> > > >>
> >> > > >
> >> > > > As I indicated in the previous message, this is functionally
> >> > > > breaking. [I'm diverting this discussion over to the "dev"
> >> > > > mailing list.]
> >> > > >
> >> > >
> >> > > Saying that making record mutable is "breaking" is a bit unfair when
> >> we
> >> > do
> >> > > NOT document the mutability of the class in the first place.
> >> > >
> >> > > Gary
> >> > >
> >> > >
> >> > > >
> >> > > > The following should be an interesting read:
> >> > > > http://markmail.org/message/6ytvmxvy2ndsfp7h
> >> > > >
> >> > > >
> >> > > > Regards,
> >> > > > Gilles
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
> >> gilles@harfang.homelinux.org
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>> > <nitin.mahendru88@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
> >> > > >>> >> <gi...@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
> >> > > >>> >> > > <gi...@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" <
> >> > britter@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
> >> > > >>> >> > >>>> <ga...@gmail.com>:
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > Gary
> >> > > >>> >> > >>>> >
> >> > > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> >> > > >>> >> <ga...@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.mahendru88@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
> >> > > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> >> > > >>> For additional commands, e-mail: user-help@commons.apache.org
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> >> > > > For additional commands, e-mail: user-help@commons.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
Hi Everyone,
Any decision on this yet ?
Thanks
Nitin
On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru <ni...@gmail.com>
wrote:
> Just another follow up. Anything new ?
>
> -Nitin
>
>
>
>
> On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Not yet ;-)
>>
>> On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com>
>> wrote:
>>
>> > Hi All,
>> >
>> > Any consensus on this ?
>> >
>> > -Nitin
>> >
>> >
>> >
>> >
>> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
>> > wrote:
>> >
>> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gilles@harfang.homelinux.org
>> >
>> > > wrote:
>> > >
>> > > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>> > > >
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>
>> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> <nitin.mahendru88@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...
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> Below is the pull request I added.
>> > > >> https://github.com/apache/commons-csv/pull/21
>> > > >>
>> > > >
>> > > > As I indicated in the previous message, this is functionally
>> > > > breaking. [I'm diverting this discussion over to the "dev"
>> > > > mailing list.]
>> > > >
>> > >
>> > > Saying that making record mutable is "breaking" is a bit unfair when
>> we
>> > do
>> > > NOT document the mutability of the class in the first place.
>> > >
>> > > Gary
>> > >
>> > >
>> > > >
>> > > > The following should be an interesting read:
>> > > > http://markmail.org/message/6ytvmxvy2ndsfp7h
>> > > >
>> > > >
>> > > > Regards,
>> > > > Gilles
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
>> gilles@harfang.homelinux.org
>> > >
>> > > >> wrote:
>> > > >>
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> > <nitin.mahendru88@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
>> > > >>> >> <gi...@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
>> > > >>> >> > > <gi...@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" <
>> > britter@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
>> > > >>> >> > >>>> <ga...@gmail.com>:
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > Gary
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>> > > >>> >> <ga...@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.mahendru88@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
>> > > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>> > > >>> For additional commands, e-mail: user-help@commons.apache.org
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> > > > For additional commands, e-mail: user-help@commons.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
Hi Everyone,
Any decision on this yet ?
Thanks
Nitin
On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru <ni...@gmail.com>
wrote:
> Just another follow up. Anything new ?
>
> -Nitin
>
>
>
>
> On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Not yet ;-)
>>
>> On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com>
>> wrote:
>>
>> > Hi All,
>> >
>> > Any consensus on this ?
>> >
>> > -Nitin
>> >
>> >
>> >
>> >
>> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
>> > wrote:
>> >
>> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gilles@harfang.homelinux.org
>> >
>> > > wrote:
>> > >
>> > > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>> > > >
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>
>> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> <nitin.mahendru88@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...
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> Below is the pull request I added.
>> > > >> https://github.com/apache/commons-csv/pull/21
>> > > >>
>> > > >
>> > > > As I indicated in the previous message, this is functionally
>> > > > breaking. [I'm diverting this discussion over to the "dev"
>> > > > mailing list.]
>> > > >
>> > >
>> > > Saying that making record mutable is "breaking" is a bit unfair when
>> we
>> > do
>> > > NOT document the mutability of the class in the first place.
>> > >
>> > > Gary
>> > >
>> > >
>> > > >
>> > > > The following should be an interesting read:
>> > > > http://markmail.org/message/6ytvmxvy2ndsfp7h
>> > > >
>> > > >
>> > > > Regards,
>> > > > Gilles
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
>> gilles@harfang.homelinux.org
>> > >
>> > > >> wrote:
>> > > >>
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> > <nitin.mahendru88@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
>> > > >>> >> <gi...@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
>> > > >>> >> > > <gi...@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" <
>> > britter@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
>> > > >>> >> > >>>> <ga...@gmail.com>:
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > Gary
>> > > >>> >> > >>>> >
>> > > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>> > > >>> >> <ga...@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.mahendru88@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
>> > > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>> > > >>> For additional commands, e-mail: user-help@commons.apache.org
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> > > > For additional commands, e-mail: user-help@commons.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
Just another follow up. Anything new ?
-Nitin
On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory <ga...@gmail.com>
wrote:
> Not yet ;-)
>
> On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > Any consensus on this ?
> >
> > -Nitin
> >
> >
> >
> >
> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
> > > wrote:
> > >
> > > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> > > >
> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > > >>
> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > > >>> <nitin.mahendru88@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...
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Below is the pull request I added.
> > > >> https://github.com/apache/commons-csv/pull/21
> > > >>
> > > >
> > > > As I indicated in the previous message, this is functionally
> > > > breaking. [I'm diverting this discussion over to the "dev"
> > > > mailing list.]
> > > >
> > >
> > > Saying that making record mutable is "breaking" is a bit unfair when we
> > do
> > > NOT document the mutability of the class in the first place.
> > >
> > > Gary
> > >
> > >
> > > >
> > > > The following should be an interesting read:
> > > > http://markmail.org/message/6ytvmxvy2ndsfp7h
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > >
> > > >
> > > >
> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
> gilles@harfang.homelinux.org
> > >
> > > >> wrote:
> > > >>
> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > > >>> > <nitin.mahendru88@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
> > > >>> >> <gi...@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
> > > >>> >> > > <gi...@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" <
> > britter@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
> > > >>> >> > >>>> <ga...@gmail.com>:
> > > >>> >> > >>>> >
> > > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> > > >>> >> > >>>> >
> > > >>> >> > >>>> > Gary
> > > >>> >> > >>>> >
> > > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> > > >>> >> <ga...@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.mahendru88@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
> > > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> > > >>> For additional commands, e-mail: user-help@commons.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: user-help@commons.apache.org
> > > >
> > > >
> > >
> >
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
Not yet ;-)
On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com> wrote:
> Hi All,
>
> Any consensus on this ?
>
> -Nitin
>
>
>
>
> On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
> > wrote:
> >
> > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> > >
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>
> > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>> <nitin.mahendru88@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...
> > >>
> > >>
> > >>
> > >>
> > >> Below is the pull request I added.
> > >> https://github.com/apache/commons-csv/pull/21
> > >>
> > >
> > > As I indicated in the previous message, this is functionally
> > > breaking. [I'm diverting this discussion over to the "dev"
> > > mailing list.]
> > >
> >
> > Saying that making record mutable is "breaking" is a bit unfair when we
> do
> > NOT document the mutability of the class in the first place.
> >
> > Gary
> >
> >
> > >
> > > The following should be an interesting read:
> > > http://markmail.org/message/6ytvmxvy2ndsfp7h
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > >
> > >
> > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gilles@harfang.homelinux.org
> >
> > >> wrote:
> > >>
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>> > <nitin.mahendru88@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
> > >>> >> <gi...@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
> > >>> >> > > <gi...@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" <
> britter@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
> > >>> >> > >>>> <ga...@gmail.com>:
> > >>> >> > >>>> >
> > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> > >>> >> > >>>> >
> > >>> >> > >>>> > Gary
> > >>> >> > >>>> >
> > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> > >>> >> <ga...@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.mahendru88@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
> > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: user-help@commons.apache.org
> > >>>
> > >>>
> > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: user-help@commons.apache.org
> > >
> > >
> >
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 18:00:54 -0600, Gary Gregory wrote:
> On Aug 18, 2017 16:10, "Gilles" <gi...@harfang.homelinux.org> wrote:
>
> On Fri, 18 Aug 2017 15:46:11 -0600, Gary Gregory wrote:
>
>> On Fri, Aug 18, 2017 at 3:38 PM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote:
>>>
>>> On Fri, Aug 18, 2017 at 12:50 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>>>>
>>>>>
>>>>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles
>>>>> <gi...@harfang.homelinux.org>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>>>>
>>>>>>
>>>>>>> Let's summarize the options:
>>>>>>>
>>>>>>>
>>>>>>>> 0) do nothing
>>>>>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>>>>>> 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
>>>>>>>>
>>>>>>>> What else?
>>>>>>>>
>>>>>>>>
>>>>>>>> 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)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> To me, that feels like bending over backwards and hard to very
>>>>>> ugly to
>>>>>> use,
>>>>>> building an array of ints, building an array of Strings. Yikes.
>>>>>> But,
>>>>>> hey
>>>>>> that's just me.
>>>>>>
>>>>>>
>>>>>> What about the "Pair" alternative above?
>>>>>
>>>>> Another alternative would be to have a "CSVRecordBuilder" (with
>>>>> "put"
>>>>> methods):
>>>>> ---CUT---
>>>>> CSVRecord rec = readRecord(source);
>>>>> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4,
>>>>> "this").build();
>>>>> ---CUT---
>>>>>
>>>>>
>>>>> For my money, the above is convoluted for no reason from a user's
>>>>> POV,
>>>>
>>>>
>>> I surely agree that the "builder" approach is less obvious
>>> than adding methods as the need seems to arise.
>>> But the part "for no reason" is simply not true.
>>>
>>> My opinion is that a library is more useful if it limits
>>> the number of ways one can shoot one's foot. YMMV. :-)
>>>
>>> What are the consequences in various use-cases?
>>> Is mutability or immutability useful in selected cases?
>>> And from there, how to modify the design to gracefully
>>> handle all of them?
>>>
>>> Assuming that you want to define a mutable class for
>>> some of those cases, it might make sense to provide
>>> a factory to create an immutable instance:
>>>
>>> public class CSVRecord {
>>>
>>> /** Deep copy constructor. */
>>> public CSVRecord(CSVRecord rec) { /* ... */ }
>>>
>>> public void put(int i, String s) { /* ... */ }
>>>
>>> /** Create an immutable copy. */
>>> public CSVRecord createImmutable() {
>>> return new CSVRecord(this) {
>>> public void put(int i, String s) {
>>> throw new UnsupportedOperationException();
>>> }
>>> }
>>> }
>>> }
>>>
>>> That way, in the new release, users that relied on the
>>> immutable character of "CSVRecord" can at least modify
>>> their code at the (hopefully few) right places and still
>>> maintain consistency.
>>>
>>
>>
>> I did something like that in the branch CSV-216 but that tweaks a
>> lot of
>> code and not every one liked that.
>>
>
> Perhaps because "mutable or not" is not part of the format...
>
> Here the immutability is provided on a per-record basis.
> Anyways, I'm not even sure that it's a good enough substitute
> for compiler-enforced immutability. :-{
>
> Finally, it boils down to what exactly the class "CSVRecord"
> represents. Your view is definitely different from the
> original designers' (perhaps a younger you was among them?).
>
>
> You are asking a lot of me as I can't recall what I had for breakfast
> ;-)
>
> When I started contributing to CVS, my use cases where read-only,
> they
> still are, but I am happy to accommodate RW use cases, one way or
> another.
> I just do not see doing it on a per record basis.
Not very useful, I agree; "CSVFormat"[1] level is fine.
Gilles
[1] The Javadoc at line 1791 must be fixed.
>
> Gary
>
>
>
> Gilles
>
>
> Gary
>>
>>
>>>
>>> Gilles
>>>
>>> again compared to the simple:
>>>
>>>>
>>>> rec.put(1, "Change");
>>>> rec.put(4, "this");
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 18, 2017 16:10, "Gilles" <gi...@harfang.homelinux.org> wrote:
On Fri, 18 Aug 2017 15:46:11 -0600, Gary Gregory wrote:
> On Fri, Aug 18, 2017 at 3:38 PM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote:
>>
>> On Fri, Aug 18, 2017 at 12:50 PM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>>>
>>>>
>>>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles <gi...@harfang.homelinux.org>
>>>>
>>>>> wrote:
>>>>>
>>>>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>>>
>>>>>
>>>>>> Let's summarize the options:
>>>>>>
>>>>>>
>>>>>>> 0) do nothing
>>>>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>>>>> 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
>>>>>>>
>>>>>>> What else?
>>>>>>>
>>>>>>>
>>>>>>> 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)
>>>>>>
>>>>>>
>>>>>>
>>>>> To me, that feels like bending over backwards and hard to very ugly to
>>>>> use,
>>>>> building an array of ints, building an array of Strings. Yikes. But,
>>>>> hey
>>>>> that's just me.
>>>>>
>>>>>
>>>>> What about the "Pair" alternative above?
>>>>
>>>> Another alternative would be to have a "CSVRecordBuilder" (with "put"
>>>> methods):
>>>> ---CUT---
>>>> CSVRecord rec = readRecord(source);
>>>> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4, "this").build();
>>>> ---CUT---
>>>>
>>>>
>>>> For my money, the above is convoluted for no reason from a user's POV,
>>>
>>>
>> I surely agree that the "builder" approach is less obvious
>> than adding methods as the need seems to arise.
>> But the part "for no reason" is simply not true.
>>
>> My opinion is that a library is more useful if it limits
>> the number of ways one can shoot one's foot. YMMV. :-)
>>
>> What are the consequences in various use-cases?
>> Is mutability or immutability useful in selected cases?
>> And from there, how to modify the design to gracefully
>> handle all of them?
>>
>> Assuming that you want to define a mutable class for
>> some of those cases, it might make sense to provide
>> a factory to create an immutable instance:
>>
>> public class CSVRecord {
>>
>> /** Deep copy constructor. */
>> public CSVRecord(CSVRecord rec) { /* ... */ }
>>
>> public void put(int i, String s) { /* ... */ }
>>
>> /** Create an immutable copy. */
>> public CSVRecord createImmutable() {
>> return new CSVRecord(this) {
>> public void put(int i, String s) {
>> throw new UnsupportedOperationException();
>> }
>> }
>> }
>> }
>>
>> That way, in the new release, users that relied on the
>> immutable character of "CSVRecord" can at least modify
>> their code at the (hopefully few) right places and still
>> maintain consistency.
>>
>
>
> I did something like that in the branch CSV-216 but that tweaks a lot of
> code and not every one liked that.
>
Perhaps because "mutable or not" is not part of the format...
Here the immutability is provided on a per-record basis.
Anyways, I'm not even sure that it's a good enough substitute
for compiler-enforced immutability. :-{
Finally, it boils down to what exactly the class "CSVRecord"
represents. Your view is definitely different from the
original designers' (perhaps a younger you was among them?).
You are asking a lot of me as I can't recall what I had for breakfast ;-)
When I started contributing to CVS, my use cases where read-only, they
still are, but I am happy to accommodate RW use cases, one way or another.
I just do not see doing it on a per record basis.
Gary
Gilles
Gary
>
>
>>
>> Gilles
>>
>> again compared to the simple:
>>
>>>
>>> rec.put(1, "Change");
>>> rec.put(4, "this");
>>>
>>> Gary
>>>
>>>
>>>
>>>>
>>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 15:46:11 -0600, Gary Gregory wrote:
> On Fri, Aug 18, 2017 at 3:38 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote:
>>
>>> On Fri, Aug 18, 2017 at 12:50 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>>>>
>>>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>>>
>>>>>>
>>>>>> Let's summarize the options:
>>>>>>
>>>>>>>
>>>>>>> 0) do nothing
>>>>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>>>>> 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
>>>>>>>
>>>>>>> What else?
>>>>>>>
>>>>>>>
>>>>>>> 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)
>>>>>>
>>>>>>
>>>>>
>>>>> To me, that feels like bending over backwards and hard to very
>>>>> ugly to
>>>>> use,
>>>>> building an array of ints, building an array of Strings. Yikes.
>>>>> But, hey
>>>>> that's just me.
>>>>>
>>>>>
>>>> What about the "Pair" alternative above?
>>>>
>>>> Another alternative would be to have a "CSVRecordBuilder" (with
>>>> "put"
>>>> methods):
>>>> ---CUT---
>>>> CSVRecord rec = readRecord(source);
>>>> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4,
>>>> "this").build();
>>>> ---CUT---
>>>>
>>>>
>>> For my money, the above is convoluted for no reason from a user's
>>> POV,
>>>
>>
>> I surely agree that the "builder" approach is less obvious
>> than adding methods as the need seems to arise.
>> But the part "for no reason" is simply not true.
>>
>> My opinion is that a library is more useful if it limits
>> the number of ways one can shoot one's foot. YMMV. :-)
>>
>> What are the consequences in various use-cases?
>> Is mutability or immutability useful in selected cases?
>> And from there, how to modify the design to gracefully
>> handle all of them?
>>
>> Assuming that you want to define a mutable class for
>> some of those cases, it might make sense to provide
>> a factory to create an immutable instance:
>>
>> public class CSVRecord {
>>
>> /** Deep copy constructor. */
>> public CSVRecord(CSVRecord rec) { /* ... */ }
>>
>> public void put(int i, String s) { /* ... */ }
>>
>> /** Create an immutable copy. */
>> public CSVRecord createImmutable() {
>> return new CSVRecord(this) {
>> public void put(int i, String s) {
>> throw new UnsupportedOperationException();
>> }
>> }
>> }
>> }
>>
>> That way, in the new release, users that relied on the
>> immutable character of "CSVRecord" can at least modify
>> their code at the (hopefully few) right places and still
>> maintain consistency.
>
>
> I did something like that in the branch CSV-216 but that tweaks a lot
> of
> code and not every one liked that.
Perhaps because "mutable or not" is not part of the format...
Here the immutability is provided on a per-record basis.
Anyways, I'm not even sure that it's a good enough substitute
for compiler-enforced immutability. :-{
Finally, it boils down to what exactly the class "CSVRecord"
represents. Your view is definitely different from the
original designers' (perhaps a younger you was among them?).
Gilles
> Gary
>
>>
>>
>> Gilles
>>
>> again compared to the simple:
>>>
>>> rec.put(1, "Change");
>>> rec.put(4, "this");
>>>
>>> Gary
>>>
>>>
>>>>
>>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 18, 2017 at 3:38 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote:
>
>> On Fri, Aug 18, 2017 at 12:50 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>>>
>>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>>
>>>>>
>>>>> Let's summarize the options:
>>>>>
>>>>>>
>>>>>> 0) do nothing
>>>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>>>> 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
>>>>>>
>>>>>> What else?
>>>>>>
>>>>>>
>>>>>> 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)
>>>>>
>>>>>
>>>>
>>>> To me, that feels like bending over backwards and hard to very ugly to
>>>> use,
>>>> building an array of ints, building an array of Strings. Yikes. But, hey
>>>> that's just me.
>>>>
>>>>
>>> What about the "Pair" alternative above?
>>>
>>> Another alternative would be to have a "CSVRecordBuilder" (with "put"
>>> methods):
>>> ---CUT---
>>> CSVRecord rec = readRecord(source);
>>> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4, "this").build();
>>> ---CUT---
>>>
>>>
>> For my money, the above is convoluted for no reason from a user's POV,
>>
>
> I surely agree that the "builder" approach is less obvious
> than adding methods as the need seems to arise.
> But the part "for no reason" is simply not true.
>
> My opinion is that a library is more useful if it limits
> the number of ways one can shoot one's foot. YMMV. :-)
>
> What are the consequences in various use-cases?
> Is mutability or immutability useful in selected cases?
> And from there, how to modify the design to gracefully
> handle all of them?
>
> Assuming that you want to define a mutable class for
> some of those cases, it might make sense to provide
> a factory to create an immutable instance:
>
> public class CSVRecord {
>
> /** Deep copy constructor. */
> public CSVRecord(CSVRecord rec) { /* ... */ }
>
> public void put(int i, String s) { /* ... */ }
>
> /** Create an immutable copy. */
> public CSVRecord createImmutable() {
> return new CSVRecord(this) {
> public void put(int i, String s) {
> throw new UnsupportedOperationException();
> }
> }
> }
> }
>
> That way, in the new release, users that relied on the
> immutable character of "CSVRecord" can at least modify
> their code at the (hopefully few) right places and still
> maintain consistency.
I did something like that in the branch CSV-216 but that tweaks a lot of
code and not every one liked that.
Gary
>
>
> Gilles
>
> again compared to the simple:
>>
>> rec.put(1, "Change");
>> rec.put(4, "this");
>>
>> Gary
>>
>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote:
> On Fri, Aug 18, 2017 at 12:50 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>>
>>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>>
>>>> Let's summarize the options:
>>>>>
>>>>> 0) do nothing
>>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>>> 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
>>>>>
>>>>> What else?
>>>>>
>>>>>
>>>> 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)
>>>>
>>>
>>>
>>> To me, that feels like bending over backwards and hard to very ugly
>>> to
>>> use,
>>> building an array of ints, building an array of Strings. Yikes.
>>> But, hey
>>> that's just me.
>>>
>>
>> What about the "Pair" alternative above?
>>
>> Another alternative would be to have a "CSVRecordBuilder" (with
>> "put"
>> methods):
>> ---CUT---
>> CSVRecord rec = readRecord(source);
>> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4,
>> "this").build();
>> ---CUT---
>>
>
> For my money, the above is convoluted for no reason from a user's
> POV,
I surely agree that the "builder" approach is less obvious
than adding methods as the need seems to arise.
But the part "for no reason" is simply not true.
My opinion is that a library is more useful if it limits
the number of ways one can shoot one's foot. YMMV. :-)
What are the consequences in various use-cases?
Is mutability or immutability useful in selected cases?
And from there, how to modify the design to gracefully
handle all of them?
Assuming that you want to define a mutable class for
some of those cases, it might make sense to provide
a factory to create an immutable instance:
public class CSVRecord {
/** Deep copy constructor. */
public CSVRecord(CSVRecord rec) { /* ... */ }
public void put(int i, String s) { /* ... */ }
/** Create an immutable copy. */
public CSVRecord createImmutable() {
return new CSVRecord(this) {
public void put(int i, String s) {
throw new UnsupportedOperationException();
}
}
}
}
That way, in the new release, users that relied on the
immutable character of "CSVRecord" can at least modify
their code at the (hopefully few) right places and still
maintain consistency.
Gilles
> again compared to the simple:
>
> rec.put(1, "Change");
> rec.put(4, "this");
>
> Gary
>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 18, 2017 at 12:50 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
>
>> On Wed, Aug 16, 2017 at 6:28 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>>
>>> Let's summarize the options:
>>>>
>>>> 0) do nothing
>>>> 1) Add two put methods to CVSRecord making the class mutable
>>>> 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
>>>>
>>>> What else?
>>>>
>>>>
>>> 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)
>>>
>>
>>
>> To me, that feels like bending over backwards and hard to very ugly to
>> use,
>> building an array of ints, building an array of Strings. Yikes. But, hey
>> that's just me.
>>
>
> What about the "Pair" alternative above?
>
> Another alternative would be to have a "CSVRecordBuilder" (with "put"
> methods):
> ---CUT---
> CSVRecord rec = readRecord(source);
> rec = new CSVRecordBuilder(rec).put(1, "Change").put(4, "this").build();
> ---CUT---
>
For my money, the above is convoluted for no reason from a user's POV,
again compared to the simple:
rec.put(1, "Change");
rec.put(4, "this");
Gary
>
>
> Gilles
>
>
>
>> Gary
>>
>>
>>>
>>> Gilles
>>>
>>>
>>>
>>> I like the simplest option: 1.
>>>>
>>>> Gary
>>>>
>>>> On Tue, Aug 15, 2017 at 6:01 PM, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
>>>>
>>>>>
>>>>> On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>>>>>
>>>>>>
>>>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>>>
>>>>>>>> <nitin.mahendru88@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...
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Below is the pull request I added.
>>>>>>>> https://github.com/apache/commons-csv/pull/21
>>>>>>>>
>>>>>>>>
>>>>>>>> As I indicated in the previous message, this is functionally
>>>>>>>>
>>>>>>> breaking. [I'm diverting this discussion over to the "dev"
>>>>>>> mailing list.]
>>>>>>>
>>>>>>>
>>>>>>> Saying that making record mutable is "breaking" is a bit unfair when
>>>>>>>
>>>>>> we do
>>>>>> NOT document the mutability of the class in the first place.
>>>>>>
>>>>>>
>>>>>> I'm stating a fact: class is currently immutable, change
>>>>> would make it mutable; it is functionally breaking.
>>>>> I didn't say that you are forbidden to do it; just that
>>>>> it would be unwise, particularly if it would be to save
>>>>> a few bytes.
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The following should be an interesting read:
>>>>>>
>>>>>>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
>>>>>>> gilles@harfang.homelinux.org>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>>>>
>>>>>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>>>
>>>>>>>>> > <nitin.mahendru88@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
>>>>>>>>> >> <gi...@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
>>>>>>>>> >> > > <gi...@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" <
>>>>>>>>> britter@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
>>>>>>>>> >> > >>>> <ga...@gmail.com>:
>>>>>>>>> >> > >>>> >
>>>>>>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>>>>>>> >> > >>>> >
>>>>>>>>> >> > >>>> > Gary
>>>>>>>>> >> > >>>> >
>>>>>>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>>>>>>> >> <ga...@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.mahendru88@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
>>>>>>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote:
> On Wed, Aug 16, 2017 at 6:28 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>>
>>> Let's summarize the options:
>>>
>>> 0) do nothing
>>> 1) Add two put methods to CVSRecord making the class mutable
>>> 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
>>>
>>> What else?
>>>
>>
>> 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)
>
>
> To me, that feels like bending over backwards and hard to very ugly
> to use,
> building an array of ints, building an array of Strings. Yikes. But,
> hey
> that's just me.
What about the "Pair" alternative above?
Another alternative would be to have a "CSVRecordBuilder" (with "put"
methods):
---CUT---
CSVRecord rec = readRecord(source);
rec = new CSVRecordBuilder(rec).put(1, "Change").put(4,
"this").build();
---CUT---
Gilles
>
> Gary
>
>>
>>
>> Gilles
>>
>>
>>
>>> I like the simplest option: 1.
>>>
>>> Gary
>>>
>>> On Tue, Aug 15, 2017 at 6:01 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
>>>>
>>>> On Tue, Aug 15, 2017 at 5:32 PM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>>>>
>>>>>>
>>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>>
>>>>>>>> <nitin.mahendru88@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...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Below is the pull request I added.
>>>>>>> https://github.com/apache/commons-csv/pull/21
>>>>>>>
>>>>>>>
>>>>>>> As I indicated in the previous message, this is functionally
>>>>>> breaking. [I'm diverting this discussion over to the "dev"
>>>>>> mailing list.]
>>>>>>
>>>>>>
>>>>>> Saying that making record mutable is "breaking" is a bit unfair
>>>>>> when
>>>>> we do
>>>>> NOT document the mutability of the class in the first place.
>>>>>
>>>>>
>>>> I'm stating a fact: class is currently immutable, change
>>>> would make it mutable; it is functionally breaking.
>>>> I didn't say that you are forbidden to do it; just that
>>>> it would be unwise, particularly if it would be to save
>>>> a few bytes.
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>> The following should be an interesting read:
>>>>>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles
>>>>>> <gi...@harfang.homelinux.org>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>>>
>>>>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>>> > <nitin.mahendru88@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
>>>>>>>> >> <gi...@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
>>>>>>>> >> > > <gi...@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" <
>>>>>>>> britter@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
>>>>>>>> >> > >>>> <ga...@gmail.com>:
>>>>>>>> >> > >>>> >
>>>>>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>>>>>> >> > >>>> >
>>>>>>>> >> > >>>> > Gary
>>>>>>>> >> > >>>> >
>>>>>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>>>>>> >> <ga...@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.mahendru88@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
>>>>>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Aug 16, 2017 at 6:28 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
>
>> Let's summarize the options:
>>
>> 0) do nothing
>> 1) Add two put methods to CVSRecord making the class mutable
>> 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
>>
>> What else?
>>
>
> 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)
To me, that feels like bending over backwards and hard to very ugly to use,
building an array of ints, building an array of Strings. Yikes. But, hey
that's just me.
Gary
>
>
> Gilles
>
>
>
>> I like the simplest option: 1.
>>
>> Gary
>>
>> On Tue, Aug 15, 2017 at 6:01 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
>>>
>>> On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>>>
>>>>>
>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>
>>>>>>> <nitin.mahendru88@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...
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Below is the pull request I added.
>>>>>> https://github.com/apache/commons-csv/pull/21
>>>>>>
>>>>>>
>>>>>> As I indicated in the previous message, this is functionally
>>>>> breaking. [I'm diverting this discussion over to the "dev"
>>>>> mailing list.]
>>>>>
>>>>>
>>>>> Saying that making record mutable is "breaking" is a bit unfair when
>>>> we do
>>>> NOT document the mutability of the class in the first place.
>>>>
>>>>
>>> I'm stating a fact: class is currently immutable, change
>>> would make it mutable; it is functionally breaking.
>>> I didn't say that you are forbidden to do it; just that
>>> it would be unwise, particularly if it would be to save
>>> a few bytes.
>>>
>>> Gilles
>>>
>>>
>>>
>>> Gary
>>>>
>>>>
>>>>
>>>> The following should be an interesting read:
>>>>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>>
>>>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>>> > <nitin.mahendru88@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
>>>>>>> >> <gi...@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
>>>>>>> >> > > <gi...@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" <
>>>>>>> britter@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
>>>>>>> >> > >>>> <ga...@gmail.com>:
>>>>>>> >> > >>>> >
>>>>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>>>>> >> > >>>> >
>>>>>>> >> > >>>> > Gary
>>>>>>> >> > >>>> >
>>>>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>>>>> >> <ga...@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.mahendru88@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
>>>>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote:
> Let's summarize the options:
>
> 0) do nothing
> 1) Add two put methods to CVSRecord making the class mutable
> 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
>
> What else?
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)
Gilles
>
> I like the simplest option: 1.
>
> Gary
>
> On Tue, Aug 15, 2017 at 6:01 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
>>
>>> On Tue, Aug 15, 2017 at 5:32 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>>>
>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>
>>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>> <nitin.mahendru88@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...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Below is the pull request I added.
>>>>> https://github.com/apache/commons-csv/pull/21
>>>>>
>>>>>
>>>> As I indicated in the previous message, this is functionally
>>>> breaking. [I'm diverting this discussion over to the "dev"
>>>> mailing list.]
>>>>
>>>>
>>> Saying that making record mutable is "breaking" is a bit unfair
>>> when we do
>>> NOT document the mutability of the class in the first place.
>>>
>>
>> I'm stating a fact: class is currently immutable, change
>> would make it mutable; it is functionally breaking.
>> I didn't say that you are forbidden to do it; just that
>> it would be unwise, particularly if it would be to save
>> a few bytes.
>>
>> Gilles
>>
>>
>>
>>> Gary
>>>
>>>
>>>
>>>> The following should be an interesting read:
>>>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles
>>>> <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>>
>>>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>>> > <nitin.mahendru88@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
>>>>>> >> <gi...@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
>>>>>> >> > > <gi...@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"
>>>>>> <br...@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
>>>>>> >> > >>>> <ga...@gmail.com>:
>>>>>> >> > >>>> >
>>>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>>>> >> > >>>> >
>>>>>> >> > >>>> > Gary
>>>>>> >> > >>>> >
>>>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>>>> >> <ga...@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.mahendru88@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
>>>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
Let's summarize the options:
0) do nothing
1) Add two put methods to CVSRecord making the class mutable
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
What else?
I like the simplest option: 1.
Gary
On Tue, Aug 15, 2017 at 6:01 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
>
>> On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>>
>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>
>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>> <nitin.mahendru88@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...
>>>>
>>>>
>>>>
>>>>
>>>> Below is the pull request I added.
>>>> https://github.com/apache/commons-csv/pull/21
>>>>
>>>>
>>> As I indicated in the previous message, this is functionally
>>> breaking. [I'm diverting this discussion over to the "dev"
>>> mailing list.]
>>>
>>>
>> Saying that making record mutable is "breaking" is a bit unfair when we do
>> NOT document the mutability of the class in the first place.
>>
>
> I'm stating a fact: class is currently immutable, change
> would make it mutable; it is functionally breaking.
> I didn't say that you are forbidden to do it; just that
> it would be unwise, particularly if it would be to save
> a few bytes.
>
> Gilles
>
>
>
>> Gary
>>
>>
>>
>>> The following should be an interesting read:
>>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>>>
>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>>
>>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>>> > <nitin.mahendru88@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
>>>>> >> <gi...@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
>>>>> >> > > <gi...@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" <br...@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
>>>>> >> > >>>> <ga...@gmail.com>:
>>>>> >> > >>>> >
>>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>>> >> > >>>> >
>>>>> >> > >>>> > Gary
>>>>> >> > >>>> >
>>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>>> >> <ga...@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.mahendru88@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
>>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote:
> On Tue, Aug 15, 2017 at 5:32 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>>
>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>
>>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>> <nitin.mahendru88@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...
>>>
>>>
>>>
>>>
>>> Below is the pull request I added.
>>> https://github.com/apache/commons-csv/pull/21
>>>
>>
>> As I indicated in the previous message, this is functionally
>> breaking. [I'm diverting this discussion over to the "dev"
>> mailing list.]
>>
>
> Saying that making record mutable is "breaking" is a bit unfair when
> we do
> NOT document the mutability of the class in the first place.
I'm stating a fact: class is currently immutable, change
would make it mutable; it is functionally breaking.
I didn't say that you are forbidden to do it; just that
it would be unwise, particularly if it would be to save
a few bytes.
Gilles
>
> Gary
>
>
>>
>> The following should be an interesting read:
>> http://markmail.org/message/6ytvmxvy2ndsfp7h
>>
>>
>> Regards,
>> Gilles
>>
>>
>>
>>
>>> On Tue, Aug 15, 2017 at 11:17 AM Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>>> > <nitin.mahendru88@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
>>>> >> <gi...@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
>>>> >> > > <gi...@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"
>>>> <br...@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
>>>> >> > >>>> <ga...@gmail.com>:
>>>> >> > >>>> >
>>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>>> >> > >>>> >
>>>> >> > >>>> > Gary
>>>> >> > >>>> >
>>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>>> >> <ga...@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.mahendru88@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
>>>> >> > >>>> <garydgregory@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.mahendru88@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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
Not yet ;-)
On Aug 17, 2017 11:34, "nitin mahendru" <ni...@gmail.com> wrote:
> Hi All,
>
> Any consensus on this ?
>
> -Nitin
>
>
>
>
> On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
> > wrote:
> >
> > > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> > >
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>
> > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>> <nitin.mahendru88@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...
> > >>
> > >>
> > >>
> > >>
> > >> Below is the pull request I added.
> > >> https://github.com/apache/commons-csv/pull/21
> > >>
> > >
> > > As I indicated in the previous message, this is functionally
> > > breaking. [I'm diverting this discussion over to the "dev"
> > > mailing list.]
> > >
> >
> > Saying that making record mutable is "breaking" is a bit unfair when we
> do
> > NOT document the mutability of the class in the first place.
> >
> > Gary
> >
> >
> > >
> > > The following should be an interesting read:
> > > http://markmail.org/message/6ytvmxvy2ndsfp7h
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > >
> > >
> > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gilles@harfang.homelinux.org
> >
> > >> wrote:
> > >>
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>> > <nitin.mahendru88@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
> > >>> >> <gi...@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
> > >>> >> > > <gi...@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" <
> britter@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
> > >>> >> > >>>> <ga...@gmail.com>:
> > >>> >> > >>>> >
> > >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> > >>> >> > >>>> >
> > >>> >> > >>>> > Gary
> > >>> >> > >>>> >
> > >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> > >>> >> <ga...@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.mahendru88@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
> > >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: user-help@commons.apache.org
> > >>>
> > >>>
> > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: user-help@commons.apache.org
> > >
> > >
> >
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
Hi All,
Any consensus on this ?
-Nitin
On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> > On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> >
> >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >>
> >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >>> <nitin.mahendru88@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...
> >>
> >>
> >>
> >>
> >> Below is the pull request I added.
> >> https://github.com/apache/commons-csv/pull/21
> >>
> >
> > As I indicated in the previous message, this is functionally
> > breaking. [I'm diverting this discussion over to the "dev"
> > mailing list.]
> >
>
> Saying that making record mutable is "breaking" is a bit unfair when we do
> NOT document the mutability of the class in the first place.
>
> Gary
>
>
> >
> > The following should be an interesting read:
> > http://markmail.org/message/6ytvmxvy2ndsfp7h
> >
> >
> > Regards,
> > Gilles
> >
> >
> >
> >
> >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
> >> wrote:
> >>
> >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >>> > <nitin.mahendru88@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
> >>> >> <gi...@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
> >>> >> > > <gi...@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" <br...@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
> >>> >> > >>>> <ga...@gmail.com>:
> >>> >> > >>>> >
> >>> >> > >>>> > Feel free to provide a PR on GitHub :-)
> >>> >> > >>>> >
> >>> >> > >>>> > Gary
> >>> >> > >>>> >
> >>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> >>> >> <ga...@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.mahendru88@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
> >>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: user-help@commons.apache.org
> >>>
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>
>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> <nitin.mahendru88@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...
>>
>>
>>
>>
>> Below is the pull request I added.
>> https://github.com/apache/commons-csv/pull/21
>>
>
> As I indicated in the previous message, this is functionally
> breaking. [I'm diverting this discussion over to the "dev"
> mailing list.]
>
Saying that making record mutable is "breaking" is a bit unfair when we do
NOT document the mutability of the class in the first place.
Gary
>
> The following should be an interesting read:
> http://markmail.org/message/6ytvmxvy2ndsfp7h
>
>
> Regards,
> Gilles
>
>
>
>
>> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> > <nitin.mahendru88@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
>>> >> <gi...@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
>>> >> > > <gi...@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" <br...@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
>>> >> > >>>> <ga...@gmail.com>:
>>> >> > >>>> >
>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>> >> > >>>> >
>>> >> > >>>> > Gary
>>> >> > >>>> >
>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>> >> <ga...@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.mahendru88@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
>>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 15, 2017 at 5:32 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>
>>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> <nitin.mahendru88@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...
>>
>>
>>
>>
>> Below is the pull request I added.
>> https://github.com/apache/commons-csv/pull/21
>>
>
> As I indicated in the previous message, this is functionally
> breaking. [I'm diverting this discussion over to the "dev"
> mailing list.]
>
Saying that making record mutable is "breaking" is a bit unfair when we do
NOT document the mutability of the class in the first place.
Gary
>
> The following should be an interesting read:
> http://markmail.org/message/6ytvmxvy2ndsfp7h
>
>
> Regards,
> Gilles
>
>
>
>
>> On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>>> > <nitin.mahendru88@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
>>> >> <gi...@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
>>> >> > > <gi...@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" <br...@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
>>> >> > >>>> <ga...@gmail.com>:
>>> >> > >>>> >
>>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>>> >> > >>>> >
>>> >> > >>>> > Gary
>>> >> > >>>> >
>>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>>> >> <ga...@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.mahendru88@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
>>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> <nitin.mahendru88@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...
>
>
>
>
> Below is the pull request I added.
> https://github.com/apache/commons-csv/pull/21
As I indicated in the previous message, this is functionally
breaking. [I'm diverting this discussion over to the "dev"
mailing list.]
The following should be an interesting read:
http://markmail.org/message/6ytvmxvy2ndsfp7h
Regards,
Gilles
>
> On Tue, Aug 15, 2017 at 11:17 AM Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > <nitin.mahendru88@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
>> >> <gi...@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
>> >> > > <gi...@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"
>> <br...@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
>> >> > >>>> <ga...@gmail.com>:
>> >> > >>>> >
>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>> >> > >>>> >
>> >> > >>>> > Gary
>> >> > >>>> >
>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>> >> <ga...@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.mahendru88@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
>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 15 Aug 2017 22:52:32 +0000, nitin mahendru wrote:
> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> <nitin.mahendru88@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...
>
>
>
>
> Below is the pull request I added.
> https://github.com/apache/commons-csv/pull/21
As I indicated in the previous message, this is functionally
breaking. [I'm diverting this discussion over to the "dev"
mailing list.]
The following should be an interesting read:
http://markmail.org/message/6ytvmxvy2ndsfp7h
Regards,
Gilles
>
> On Tue, Aug 15, 2017 at 11:17 AM Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > <nitin.mahendru88@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
>> >> <gi...@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
>> >> > > <gi...@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"
>> <br...@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
>> >> > >>>> <ga...@gmail.com>:
>> >> > >>>> >
>> >> > >>>> > Feel free to provide a PR on GitHub :-)
>> >> > >>>> >
>> >> > >>>> > Gary
>> >> > >>>> >
>> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>> >> <ga...@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.mahendru88@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
>> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> <nitin.mahendru88@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...
Below is the pull request I added.
https://github.com/apache/commons-csv/pull/21
On Tue, Aug 15, 2017 at 11:17 AM Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > <nitin.mahendru88@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
> >> <gi...@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
> >> > > <gi...@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" <br...@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
> >> > >>>> <ga...@gmail.com>:
> >> > >>>> >
> >> > >>>> > Feel free to provide a PR on GitHub :-)
> >> > >>>> >
> >> > >>>> > Gary
> >> > >>>> >
> >> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
> >> <ga...@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.mahendru88@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
> >> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> <nitin.mahendru88@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
>> <gi...@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
>> > > <gi...@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" <br...@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
>> > >>>> <ga...@gmail.com>:
>> > >>>> >
>> > >>>> > Feel free to provide a PR on GitHub :-)
>> > >>>> >
>> > >>>> > Gary
>> > >>>> >
>> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory"
>> <ga...@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.mahendru88@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
>> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru <nitin.mahendru88@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 <gi...@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
> > > <gi...@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" <br...@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
> > >>>> <ga...@gmail.com>:
> > >>>> >
> > >>>> > Feel free to provide a PR on GitHub :-)
> > >>>> >
> > >>>> > Gary
> > >>>> >
> > >>>> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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
> > >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
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 <gi...@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
> > <gi...@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" <br...@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
> >>>> <ga...@gmail.com>:
> >>>> >
> >>>> > Feel free to provide a PR on GitHub :-)
> >>>> >
> >>>> > Gary
> >>>> >
> >>>> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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
> >>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
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
> <gi...@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" <br...@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
>>>> <ga...@gmail.com>:
>>>> >
>>>> > Feel free to provide a PR on GitHub :-)
>>>> >
>>>> > Gary
>>>> >
>>>> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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
>>>> <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
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 <gi...@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" <br...@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 <ga...@gmail.com>:
>>> >
>>> > Feel free to provide a PR on GitHub :-)
>>> >
>>> > Gary
>>> >
>>> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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 <garydgregory@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.mahendru88@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <br...@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
>> <ga...@gmail.com>:
>> >
>> > Feel free to provide a PR on GitHub :-)
>> >
>> > Gary
>> >
>> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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
>> <ga...@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.mahendru88@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
How does that work when you want to change more than one value?
Gary
On Aug 15, 2017 00:17, "Benedikt Ritter" <br...@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 <ga...@gmail.com>:
> >
> > Feel free to provide a PR on GitHub :-)
> >
> > Gary
> >
> > On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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 <ga...@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.mahendru88@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [CSV] CSVMutableRecord
Posted by Benedikt Ritter <br...@apache.org>.
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 <ga...@gmail.com>:
>
> Feel free to provide a PR on GitHub :-)
>
> Gary
>
> On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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 <ga...@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.mahendru88@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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
Feel free to provide a PR on GitHub :-)
Gary
On Aug 14, 2017 15:29, "Gary Gregory" <ga...@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.mahendru88@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 <ga...@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.mahendru88@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
>> > >
>> >
>>
>
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
I think we've kept the design as YAGNI as possible... :-)
Gary
On Mon, Aug 14, 2017 at 3:25 PM, nitin mahendru <ni...@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 <ga...@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.mahendru88@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
> > >
> >
>
Re: [CSV] CSVMutableRecord
Posted by nitin mahendru <ni...@gmail.com>.
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 <ga...@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.mahendru88@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
> >
>
Re: [CSV] CSVMutableRecord
Posted by Gary Gregory <ga...@gmail.com>.
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 <ni...@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
>