Re: [CSV] CSVMutableRecord
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 ... 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 wrote: On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote: On Tue, Aug 15, 2017 at 5:32 PM, Gilles wrote: On Tue, 15 Aug 2017 22:52:32 +, 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 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 wrote: On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote: > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru > > wrote: > >> How about having a state in the class itself which says that it's >> mutable >> or not. >> If we call a setter on an immutable then it throws an exception. >> By default the records are immutable and you need to make them >> mutable >> using a new API. 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 >> >> wrote: >> >> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote: >> > > That looks odd to me. What comes up for me is the use case where >> I >> > > want to >> > > ETL a file of 10,000,000 records and update, say, one column. If >> am >> > > forced >> > > to create a brand new record for every record read, that would >> be a >> > > shame. >> > >> > Why? >> > >> > > If I had a mutable record, I could just keep on updating it and >> using >> > > it to >> > > write each row. Read record, update it, write record. No extra >> memory >> > > needed. >> > >> > How is the size of 1 additional record going to matter compared to >> the >> > size of the whole program? >> > >> > > Either we can make the current record mutable (what's the harm?) >> or >> > > we can >> > > make the parser serve out mutable records based on a config >> setting. >> > > This >> > > could be a subclass of CSVRecord with the extra method I >> proposed. >> > >> > The harm is that you loose all the promises of immutability. >> > >> > Regards, >> > Gilles >> > >> > > >> > > Thoughts? >> > > >> > > Gary >> > > >> > > On Tue, Aug 15, 2017 at 8:33 AM, Gilles >> > > >> > > wrote: >> > > >> > >> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote: >> > >> >> > >>> How does that work when you want to change more
[RESULT] [VOTE] Release Apache Commons JCS 2.2 based on RC1
On 02.08.17 15:32, Thomas Vandahl wrote: > I would like to release the [jcs] component to resolve some overdue bugs > > Apache Commons JCS 2.2 RC1 is available for review at: > https://dist.apache.org/repos/dist/dev/commons/jcs/ (r20728). Time to wrap up. The following votes were cast (in order of appearance): Thomas Vandahl: +1 Romain Manni-Bucau: +1 (non binding) Oliver Heger: +1 Amey Jadiye: +1 (non-binding) Gary Gregory: +1 Rob Tompkins: +1 The vote has passed. Thanks to all the voters! I'll proceed with the release procedure. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1
For some reason, your mail was sent to me personally only. Bye, Thomas. Forwarded Message Subject:Re: [VOTE] Release Apache Commons JCS 2.2 based on RC1 Date: Mon, 14 Aug 2017 13:51:55 -0600 From: Gary Gregory To: Thomas Vandahl +1 Tests finally pass (must have been a random fail). I ran the build a three times with "mvn clean verify". ASC OK, MD5 OK, SHA1 OK. RAT check OK. Site Reports look ok. Using: Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00) Maven home: C:\Java\apache-maven-3.5.0\bin\.. Java version: 1.7.0_80, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_80\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows" Java 8 build fails with Javadoc errors. Gary On Thu, Aug 10, 2017 at 10:27 AM, Gary Gregory mailto:garydgreg...@gmail.com>> wrote: I will try again today... Gary On Aug 10, 2017 09:51, "Thomas Vandahl" mailto:t...@apache.org>> wrote: Hi Gary, On 10.08.17 07:54, Gary Gregory wrote: > This VOTE is 7 days old. Has it been tallied? Did I miss it? AFAIK, we are still one PMC vote short. Did you manage to create a clean build? The test you mentioned may be time sensitive on a Windows platform. Then your vote would be helpful. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] CSVMutableRecord
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 wrote: > On Tue, 15 Aug 2017 17:43:26 -0600, Gary Gregory wrote: > >> On Tue, Aug 15, 2017 at 5:32 PM, Gilles >> wrote: >> >> On Tue, 15 Aug 2017 22:52:32 +, 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 > > 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 wrote: On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote: > > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru > > >> wrote: > > > >> How about having a state in the class itself which says that it's > >> mutable > >> or not. > >> If we call a setter on an immutable then it throws an exception. > >> By default the records are immutable and you need to make them > >> mutable > >> using a new API. > > 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 > >> > >> 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 > >> > > >> > > > >> > > Though
