That sounds good to me too. The less duplication, the better.
Gary
On Aug 14, 2013, at 18:16, James Carman wrote:
> I would say we should extract the conversion stuff out of [beanutils]
> and create [convert] (with some modifications to the API perhaps) an
> have [beanutils] use the new compone
On 14 August 2013 23:34, Gilles wrote:
>
> At this point, I'd tend to think that creating a copy of trunk in the
> Commons's "sandbox" part of the repository will be more productive.
Why sandbox? Just use a temporary branch in the existing math repo.
> There, we can both directly modify the code
Hi.
> [...]
Since the iteration counter was incremented explicitly I thought it
made
sense to increment the evaluation counter explicitly.
It's indeed cleaner to have the two counters handled in a similar
fashion. Actually, the iteration counter was an afterthought: Driven
by my current usa
I would say we should extract the conversion stuff out of [beanutils]
and create [convert] (with some modifications to the API perhaps) an
have [beanutils] use the new component.
On Wed, Aug 14, 2013 at 5:57 PM, Paul Benedict wrote:
> Two weeks ago, I mentioned that BeanUtils and Convert heavily
Two weeks ago, I mentioned that BeanUtils and Convert heavily overlap. Some
others agreed. Do we want to fold one project into the other? Or can we
find justification to have 2 separate conversion projects?
--
Cheers,
Paul
On Wed, Aug 14, 2013 at 4:04 PM, Emmanuel Bourg wrote:
>
> That being said, [convert] could offer several patterns to perform type
> conversion, and the use of proxies could be one of them.
>
>
I know of a project that might be able to help you with those proxies, too! :)
---
Hi,
On 08/14/2013 12:23 PM, Konstantin Berlin wrote:
> Since I have no idea what you guys are describing, could you guys please
> do something like this? Or at least put rough outlines of the interfaces
> and classes somewhere, so other people can evaluate?
The *rough* interfaces and classes of m
Emmanuel, yes. Both the CVSParser and Iterator are two distinct designs.
Both are types of parsers here. So it's really a question of design. Do you
want your users to use the parser directly or work through the iterator or
both? But they shouldn't interfere with each other.
Example:
CVSParser p =
On 08/14/2013 11:30 AM, Gilles wrote:
> On Tue, 13 Aug 2013 17:47:18 -0400, Evan Ward wrote:
>> On 08/13/2013 08:17 AM, Gilles wrote:
(I.e. GN would
not need 5 superclasses and fields for storing upper and lower
bounds.)
>>>
>>> Be careful: "GaussNewtonOptimizer" does _not_ support
Le 14/08/2013 20:22, Benedikt Ritter a écrit :
Thanks for the input. Now is the time to talk about this kind of stuff.
I understand Matt's proposal and it should be relatively easy to implement.
However I see Paul's point but don't know yet how to develop the API the
way he suggests.
Paul can yo
On 8/14/2013 1:10 PM, Emmanuel Bourg wrote:
Le 14/08/2013 20:09, Benedikt Ritter a écrit :
Every factory method an the constructor now take a CSVFormat. How about
using CSVFormat.DEFAULT is null is passed as CSVFormat?
Keeping null is better, using the default format might hide a bug in
the
The only danger of static methods is that you can't override them.
BeanUtils first suffered from this fate and they then made an instance
version (BeanUtils2). Just said plainly, you can't customize well using
factory classes/methods.
On Wed, Aug 14, 2013 at 3:04 PM, Emmanuel Bourg wrote:
> Le
Le 14/08/2013 20:09, Benedikt Ritter a écrit :
Every factory method an the constructor now take a CSVFormat. How about
using CSVFormat.DEFAULT is null is passed as CSVFormat?
Keeping null is better, using the default format might hide a bug in the
calling code, and it could be difficult to fi
Le 14/08/2013 17:39, Adrian Crum a écrit :
Instead of
int columnInt = record.getValueAsInt(1);
the developer would use
Integer columnInt = Util.convertTo(record.getValue(1), Integer.class);
+1 for the static method, that would allow the use of a static import
and a very concise syntax like
Am 14.08.2013 17:39, schrieb Adrian Crum:
> I don't think CSV needs anything special to accommodate type conversion.
>
> The pattern I tried to introduce in the Commons Convert "Getting
> Started" section is one that works in any part of an application where
> conversion might be needed. So, inste
Am 14.08.2013 16:54, schrieb Gary Gregory:
> On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
> wrote:
>
>> Hi all,
>>
>> recently, there was a discussion about extending the [csv] interface to
>> provide data conversions to different types. If such a use case is to be
>> supported, what would be the
On Wed, Aug 14, 2013 at 2:09 PM, Benedikt Ritter wrote:
> Done in revision 1513994.
>
> Every factory method an the constructor now take a CSVFormat. How about
> using CSVFormat.DEFAULT is null is passed as CSVFormat?
>
Seems reasonable.
Gary
>
> Benedikt
>
>
> 2013/8/14 Matt Benson
>
> > To
The Iterator should contain a Parser, but not the other way around.
-Adrian
On 8/14/2013 11:22 AM, Benedikt Ritter wrote:
Thanks for the input. Now is the time to talk about this kind of stuff.
I understand Matt's proposal and it should be relatively easy to implement.
However I see Paul's poi
Thanks for the input. Now is the time to talk about this kind of stuff.
I understand Matt's proposal and it should be relatively easy to implement.
However I see Paul's point but don't know yet how to develop the API the
way he suggests.
Paul can your point be summed up as: Either expose an iterat
Hi Matt,
2013/8/13 Matt Benson
> Benedikt, I take your point about prematurely promoted components, and as
> one of the primary remaining participants in [functor] I take
> responsibility for that; however the promotion was made in good faith only
> last-minute discussions about the API (like th
Done in revision 1513994.
Every factory method an the constructor now take a CSVFormat. How about
using CSVFormat.DEFAULT is null is passed as CSVFormat?
Benedikt
2013/8/14 Matt Benson
> To stir the pot, one might even make a case for using Reader only ;-) .
>
> Matt
> On Aug 14, 2013 8:03 AM
Could we create an "o.a.c.m.experimental" sub-package, and put
> "competing" designs inside it: e.g.
> o.a.c.m.experimental.evan
> o.a.c.m.experimental.gilles
> for people to test with 3.3, and postpone a decision until we can see
> better the differences? Maybe this would allow to pick all the
I don't think CSV needs anything special to accommodate type conversion.
The pattern I tried to introduce in the Commons Convert "Getting
Started" section is one that works in any part of an application where
conversion might be needed. So, instead of hard-coding conversions, the
developer cre
On Tue, 13 Aug 2013 17:47:18 -0400, Evan Ward wrote:
On 08/13/2013 08:17 AM, Gilles wrote:
(I.e. GN would
not need 5 superclasses and fields for storing upper and lower
bounds.)
Be careful: "GaussNewtonOptimizer" does _not_ support bounds!
That is my point! Because of it's complex inheritan
On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
wrote:
> Hi all,
>
> recently, there was a discussion about extending the [csv] interface to
> provide data conversions to different types. If such a use case is to be
> supported, what would be the best approach to integrate a library like
> [convert]
To stir the pot, one might even make a case for using Reader only ;-) .
Matt
On Aug 14, 2013 8:03 AM, "Gary Gregory" wrote:
> On Wed, Aug 14, 2013 at 2:44 AM, Benedikt Ritter
> wrote:
>
> > 2013/8/12 Gary Gregory
> >
> > > On Mon, Aug 12, 2013 at 3:13 PM, Benedikt Ritter
> > > wrote:
> > >
>
Thanks for taking an interest, Seb! I'll work on these today.
Matt
On Aug 14, 2013 2:56 AM, "sebb" wrote:
> On 13 August 2013 23:01, wrote:
> > Author: mbenson
> > Date: Tue Aug 13 22:01:48 2013
> > New Revision: 1513669
> >
> > URL: http://svn.apache.org/r1513669
> > Log:
> > pom cleanup
> >
On Wed, Aug 14, 2013 at 2:44 AM, Benedikt Ritter wrote:
> 2013/8/12 Gary Gregory
>
> > On Mon, Aug 12, 2013 at 3:13 PM, Benedikt Ritter
> > wrote:
> >
> > > 2013/8/8 Gary Gregory
> > >
> > > > On Thu, Aug 8, 2013 at 10:27 AM, Benedikt Ritter >
> > > > wrote:
> > > >
> > > > > 2013/8/8 Emmanue
On 14 August 2013 06:02, Himanshu Gusain -X (hgusain - ARICENT
TECHNOLOGIES MAURIITIUS LIMITED at Cisco) wrote:
> Hi ,
>
> We are using Commons logging jar by apache.
> But, due to new java 7 releases by oracle our applet starts throwing the new
> prompts they introduced for mixed code in their
On 13 August 2013 23:01, wrote:
> Author: mbenson
> Date: Tue Aug 13 22:01:48 2013
> New Revision: 1513669
>
> URL: http://svn.apache.org/r1513669
> Log:
> pom cleanup
>
> Modified:
> commons/sandbox/weaver/trunk/ant/lib/pom.xml
>
> Modified: commons/sandbox/weaver/trunk/ant/lib/pom.xml
> URL
On 14 August 2013 07:44, Benedikt Ritter wrote:
> 2013/8/12 Gary Gregory
>
>> On Mon, Aug 12, 2013 at 3:13 PM, Benedikt Ritter
>> wrote:
>>
>> > 2013/8/8 Gary Gregory
>> >
>> > > On Thu, Aug 8, 2013 at 10:27 AM, Benedikt Ritter
>> > > wrote:
>> > >
>> > > > 2013/8/8 Emmanuel Bourg
>> > > >
>>
31 matches
Mail list logo
