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 at 12:50 PM, Gilles
>>> wrote:
>>>
>>> On Fri, 18 Aug 2017 12
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 12:41:01 -0600, Gary Gregory wrote:
On Wed, Aug 16, 2017 at
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 Wed, Aug 16, 2017 at 6:28 PM, Gilles
wrote:
On
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 11:27:53 -0600, Gary Gregory wrote:
Let's summarize the opt
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 p
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:
>>>
>>> Let's summarize the options:
0) do nothing
1) Add
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 in my eariler message.
>>>
>>
>>
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 silen
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 mutable
2) Add a "mutableRecord" bo
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 nat
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 not OK to not acknowledge the
>
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 to CVSRecord and CSVFormat such
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 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 KISS implementation that uses a
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 h
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. In my opinion it's bad style to add
> > types
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
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,
> Benedikt
> schrieb am Fr.
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 wrote:
> On Au
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:
> refs/heads/master 431f8236e -> 25981
20 matches
Mail list logo
