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
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
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
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
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
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:
>>>
>>>
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 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
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
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
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
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
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
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
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.
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,
>
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
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:
>
20 matches
Mail list logo