Le 23/01/2014 08:03, Benedikt Ritter a écrit :
> I personally don't like alphabetically sorted classes. For example if a
> public method calls a private method, I like to have the private method
> beneath the public method that uses it. This way I can read through a claa
> top to bottom without out
On Thu, Jan 23, 2014 at 2:03 AM, Benedikt Ritter wrote:
> I personally don't like alphabetically sorted classes. For example if a
> public method calls a private method, I like to have the private method
> beneath the public method that uses it. This way I can read through a claa
> top to bottom
I personally don't like alphabetically sorted classes. For example if a
public method calls a private method, I like to have the private method
beneath the public method that uses it. This way I can read through a claa
top to bottom without out to much jumping back and forth. But that's just a
matt
Hi Gilles,
Gilles wrote:
> On Wed, 22 Jan 2014 14:54:49 -0800, Phil Steitz wrote:
>> On 1/22/14, 2:43 PM, Jörg Schaible wrote:
>>> Jörg Schaible wrote:
>>>
Phil Steitz wrote:
> On 1/22/14, 1:58 PM, Jörg Schaible wrote:
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>> [sni
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27856&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 22 Jan 2014 23:20:45 +
Finished at: Wed 22 Jan 2014 23:25:40 +
Total time: 4m 55s
Build Trigger: Schedule
On Wed, 22 Jan 2014 14:54:49 -0800, Phil Steitz wrote:
On 1/22/14, 2:43 PM, Jörg Schaible wrote:
Jörg Schaible wrote:
Phil Steitz wrote:
On 1/22/14, 1:58 PM, Jörg Schaible wrote:
Hi Gilles,
Gilles wrote:
[snip]
It's a convention; the "component" part could be the component's
name
i.e. C
On 1/22/14, 2:43 PM, Jörg Schaible wrote:
> Jörg Schaible wrote:
>
>> Phil Steitz wrote:
>>
>>> On 1/22/14, 1:58 PM, Jörg Schaible wrote:
Hi Gilles,
Gilles wrote:
[snip]
> It's a convention; the "component" part could be the component's name
> i.e. Commons Ma
Hello,
In order to avoid "dependency hell" the Apache Commons team makes it
common practice to change the artifact name when making a release that
breaks compatibility with previous releases. In addition, we have begun
making these new releases under the org.apache.commons Maven group, so the
ar
Hi All,
I have been using commons-collections for my project and I find it very
helpful. Thanks to the developer community who has contributed to that. I
am trying to add a maven dependency to the latest commons-collections
package, which I see from the site is 4.0 (
http://commons.apache.org/pro
Jörg Schaible wrote:
> Phil Steitz wrote:
>
>> On 1/22/14, 1:58 PM, Jörg Schaible wrote:
>>> Hi Gilles,
>>>
>>> Gilles wrote:
>>>
>>> [snip]
>>>
It's a convention; the "component" part could be the component's name
i.e. Commons Math could give "commons-math" as a base name; then the
>
Phil Steitz wrote:
> On 1/22/14, 1:58 PM, Jörg Schaible wrote:
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>> [snip]
>>
>>> It's a convention; the "component" part could be the component's name
>>> i.e. Commons Math could give "commons-math" as a base name; then the
>>> artefacts (archives and JAR file
On 1/22/14, 1:58 PM, Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
> [snip]
>
>> It's a convention; the "component" part could be the component's name
>> i.e. Commons Math could give "commons-math" as a base name; then the
>> artefacts (archives and JAR files) would be differentiated sole
Hi Gilles,
Gilles wrote:
[snip]
> It's a convention; the "component" part could be the component's name
> i.e. Commons Math could give "commons-math" as a base name; then the
> artefacts (archives and JAR files) would be differentiated solely on
> the version number:
>commons-math-3.3.tar.g
On Wed, 22 Jan 2014 09:15:16 -0800, Phil Steitz wrote:
On 1/20/14, 6:40 AM, sebb wrote:
On 20 January 2014 13:18, Gilles
wrote:
On Mon, 20 Jan 2014 11:14:21 + (UTC), Emmanuel Bourg (JIRA)
wrote:
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.iss
On 1/20/14, 6:40 AM, sebb wrote:
> On 20 January 2014 13:18, Gilles wrote:
>> On Mon, 20 Jan 2014 11:14:21 + (UTC), Emmanuel Bourg (JIRA) wrote:
>>> [
>>>
>>>
>>> https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommen
Personally, I would like to see CSV record made mutable. You could get
one from the parser, make a few changes to it, then pass it to the
printer.
-Adrian
Quoting Gary Gregory :
On Wed, Jan 22, 2014 at 11:03 AM, wrote:
There is no question your use case is convenient, but it violates th
On Wed, Jan 22, 2014 at 11:27 AM, James Ring wrote:
> There is nothing that says Map must be mutable, even the javadoc says:
>
> "put - Associates the specified value with the specified key in this
> map (optional operation)."
>
Hm, good point, so we could have CSVRecord implement Map but throw
There is nothing that says Map must be mutable, even the javadoc says:
"put - Associates the specified value with the specified key in this
map (optional operation)."
On Wed, Jan 22, 2014 at 8:03 AM, wrote:
> There is no question your use case is convenient, but it violates the
> contract that
On Wed, Jan 22, 2014 at 11:03 AM, wrote:
> There is no question your use case is convenient, but it violates the
> contract that a CSV record is read-only. Calling put() on a CSV record is a
> mutating operation.
>
> So, is a CSV record read-only or not?
That the heart of the matter indeed.
For
There is no question your use case is convenient, but it violates the
contract that a CSV record is read-only. Calling put() on a CSV record
is a mutating operation.
So, is a CSV record read-only or not?
-Adrian
Quoting Gary Gregory :
On Wed, Jan 22, 2014 at 10:04 AM, wrote:
I disagree.
On Wed, Jan 22, 2014 at 10:04 AM, wrote:
> I disagree. If the CSV record is read-only, then the List and Map
> representations of the CSV record should be read-only too. Making those
> representations writable is confusing - it gives the impression you are
> modifying the CSV record when in fact y
I disagree. If the CSV record is read-only, then the List and Map
representations of the CSV record should be read-only too. Making
those representations writable is confusing - it gives the impression
you are modifying the CSV record when in fact you are not.
I don't see how it restricts t
On Wed, Jan 22, 2014 at 9:40 AM, wrote:
> CORRECTION: The patch in the Jira issue is a simplified version of Gary's
> implementation.
>
> I started with the design I proposed - an inner class Map implementation
> backed by CSVRecord, but then implementing entrySet() and such became
> complicated.
CORRECTION: The patch in the Jira issue is a simplified version of
Gary's implementation.
I started with the design I proposed - an inner class Map
implementation backed by CSVRecord, but then implementing entrySet()
and such became complicated. So I changed it to the inner class being
ba
Le 22/01/2014 14:41, Adrian Crum a écrit :
> I agree with Emmanuel. We don't want CSVRecord to devolve into a god
> class that tries to be everything to everybody. "Do only one thing, and
> do it really well" is the design pattern I prefer.
>
> I created a patch for the design I proposed a few day
I agree with Emmanuel. We don't want CSVRecord to devolve into a god
class that tries to be everything to everybody. "Do only one thing, and
do it really well" is the design pattern I prefer.
I created a patch for the design I proposed a few days ago. Please
consider using it.
https://issues
2014/1/22 Emmanuel Bourg
> Le 21/01/2014 15:08, Gary Gregory a écrit :
>
> > This kind of complication is unnecessary IMO, why not just have the
> record
> > implement Map?
>
> Because a record is neither a List nor a Map.
>
+1
>
> A map decorator isn't that complicated, and the work has alrea
Le 21/01/2014 15:08, Gary Gregory a écrit :
> This kind of complication is unnecessary IMO, why not just have the record
> implement Map?
Because a record is neither a List nor a Map.
A map decorator isn't that complicated, and the work has already been
done in [configuration]. It would be trivi
This all sounds reasonable.
G
Original message
From: Benedikt Ritter
Date:01/22/2014 05:15 (GMT-05:00)
To: Commons Developers List
Subject: Re: [LANG] New class called StringAlgorithms?
Hello,
2014/1/22 Henri Yandell
> On Mon, Jan 20, 2014 at 8:01 AM, Benedikt Ritt
Hello,
2014/1/22 Henri Yandell
> On Mon, Jan 20, 2014 at 8:01 AM, Benedikt Ritter
> wrote:
>
> > 2014/1/18 Oliver Heger
> >
> > >
> > >
> > > Am 18.01.2014 17:40, schrieb Emmanuel Bourg:
> > > > Le 18/01/2014 16:04, Benedikt Ritter a écrit :
> > > >
> > > >> About putting this into codec: I s
Github user elindsey closed the pull request at:
https://github.com/apache/commons-lang/pull/14
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On Mon, Jan 20, 2014 at 8:01 AM, Benedikt Ritter wrote:
> 2014/1/18 Oliver Heger
>
> >
> >
> > Am 18.01.2014 17:40, schrieb Emmanuel Bourg:
> > > Le 18/01/2014 16:04, Benedikt Ritter a écrit :
> > >
> > >> About putting this into codec: I still don't think this is a good fit
> > for
> > >> this
32 matches
Mail list logo
