Re: [CSV] CSVMutableRecord

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 wrote: > On Fri, 18 Aug 2017 09:36:06 -0600, Gary Gregory wrote: > >> Please see branch CSV-216 for a

Re: [CSV] CSVMutableRecord

On Wed, Aug 16, 2017 at 6:28 PM, Gilles 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

Re: [CSV] CSVMutableRecord

On Fri, Aug 18, 2017 at 12:50 PM, Gilles wrote: > On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote: > >> On Wed, Aug 16, 2017 at 6:28 PM, Gilles >> wrote: >> >> On Wed, 16 Aug 2017 11:27:53 -0600, Gary Gregory wrote: >>> >>>

Re: [CSV] CSVMutableRecord

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

Re: [CSV] CSVMutableRecord

On Fri, Aug 18, 2017 at 12:41 PM, Gilles 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

[GitHub] commons-io pull request #42: [IO-546] ClosedOutputStream#flush should throw

GitHub user tjcelaya opened a pull request: https://github.com/apache/commons-io/pull/42 [IO-546] ClosedOutputStream#flush should throw While debugging an issue involving usage of `CloseShieldOutputStream` I discovered that `ClosedOutputStream#flush` is not overridden and will

Re: [compress] Tar stream signature detection regression as of 1.11

On 2017-08-11, Philipp Grasboeck wrote: > I think I may have found a regression in > ArchiveFormatFactory.createArchiveInputStream. > Please run the JUnit testcase at the end of this mail. > It demonstrates the archive detection working with 1.10, but failing from > 1.11 through 1.14 As already

Re: [CSV] CSVMutableRecord

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

Re: [CSV] CSVMutableRecord

On Fri, Aug 18, 2017 at 11:52 AM, 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

Re: [CSV] CSVMutableRecord

On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote: On Wed, Aug 16, 2017 at 6:28 PM, Gilles 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

Re: [CSV] CSVMutableRecord

On Fri, Aug 18, 2017 at 3:38 PM, Gilles wrote: > On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote: > >> On Fri, Aug 18, 2017 at 12:50 PM, Gilles >> wrote: >> >> On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote: >>> >>> On

Re: [CSV] CSVMutableRecord

On Fri, 18 Aug 2017 15:46:11 -0600, Gary Gregory wrote: On Fri, Aug 18, 2017 at 3:38 PM, Gilles wrote: On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote: On Fri, Aug 18, 2017 at 12:50 PM, Gilles wrote: On Fri, 18 Aug 2017

Re: [CSV] CSVMutableRecord

On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote: On Fri, Aug 18, 2017 at 12:50 PM, Gilles wrote: On Fri, 18 Aug 2017 12:41:01 -0600, Gary Gregory wrote: On Wed, Aug 16, 2017 at 6:28 PM, Gilles wrote: On Wed, 16 Aug 2017

Re: [CSV] CSVMutableRecord

On Aug 18, 2017 16:10, "Gilles" wrote: On Fri, 18 Aug 2017 15:46:11 -0600, Gary Gregory wrote: > On Fri, Aug 18, 2017 at 3:38 PM, Gilles > wrote: > > On Fri, 18 Aug 2017 13:21:45 -0600, Gary Gregory wrote: >> >> On Fri, Aug 18, 2017

Re: commons-csv git commit: Better ivar name.

Hello, I don't think this is a better name. In my opinion it's bad style to add types to variable names. How about recordContents or simply content/s ? Regards, Benedikt schrieb am Fr. 18. Aug. 2017 um 17:02: > Repository: commons-csv > Updated Branches: >

Re: commons-csv git commit: Better ivar name.

I have no problem calling it a *List if it is a list, but I also have to ask should it be a list. Why not just a Collection? Is order important? Are duplicates allowed (if not perhaps a Set is proper). On the other hand it is fairly localized so I am not concerned. As for the *Map I find that

Re: [CSV] CSVMutableRecord

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

Re: commons-csv git commit: Better ivar name.

We already have header*Map* ... Gary On Fri, Aug 18, 2017 at 9:23 AM, Benedikt Ritter wrote: > Hello, > > I don't think this is a better name. In my opinion it's bad style to add > types to variable names. How about recordContents or simply content/s ? > > Regards, >

Re: commons-csv git commit: Better ivar name.

IMHO that's a bad name as well :o) Gary Gregory schrieb am Fr. 18. Aug. 2017 um 17:37: > We already have header*Map* ... > > Gary > > On Fri, Aug 18, 2017 at 9:23 AM, Benedikt Ritter > wrote: > > > Hello, > > > > I don't think this is a better name.

Re: [CSV] CSVMutableRecord

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