commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From br...@worden.org
Subject Re: [math][functor] More Design Concerns
Date Tue, 01 Jul 2003 19:19:13 GMT
On Tue, 01 Jul 2003 14:40:16 -0400, "Mark R. Diggory" wrote:

> 
> Brent Worden wrote:
> 
> >This example also helps illustrate what I would like the design of
the
> >library to proceed:
> >1) There are a collection of utility objects to perform standard
> operations
> >on standard input.  StatUtils is a good example of this.
> >2) Factories to create operation objects that perform the same
> operations on
> >both standard input and non-standard input.
> >
> So, are (1) implemented using (2) ?

In all but the most trivial of cases I would say yes.  For example, I
would change StatUtils to use the univariate classes.  Others have
cautioned against this because of the vast univariate interface but I
think I addressed these in my just-posted utopia univariate
implementation.

> 
> >3) Operational objects which allow open-ended input thus becoming
> reusable
> >in all kinds of environments.  This also prevents the need to
> implemented
> >more than once for the various inputs.
> >
> >Brent Worden
> >Senior Technical Consultant
> >Perficient, Inc. - Minneapolis
> >D: (612) 752-1625
> >  
> >
> 
> I think we have some concerns that have been voiced about becoming 
> dependent on another sandbox component (Functor) and there are also 
> arguments concerning return values that are Objects vs. return
values 
> that are Primitives. I think a logical consideration is that with 
> "Functor" like development, there will be a path of refactoring over 
> time as both math and functors mature/graduate to commons proper. 
As 
> such, much of th previous discusion revolved around the
possibilityof  
> estabishing Interfaces that copy/extend Functors capabilities with 
> primitive return values while providing a future point of
"extension" 
> for the math library once (and if) the Functor Library graduates?

I would steer away for primative as much as possible.  Mainly for the
sake of flexibility of the library and compatibility with other
commons projects.  I have no problem with using primatives in the
utility / convenience methods, but for the deep-down inards of the
library I would prefer be all object driven.

> 
> Part of this issue is technical the other political, no matter how 
> bright Functors future looks bright. It isn't going to be available
as
> a 
> maven/build dependency until it graduates. Now, it can be added as a 
> dependency in maven/project.xml, but its jar would need to be
provided 
> locally, project.xml can be configured to resolve a dependnecy
> locally, 
> I'm not sure how this would effect the build.xml generation and
would 
> have to test it before I can say for sure that its possible to have
> the 
> generated ant script also handle this appropriately.
> 

I share those concerns and maybe Rod or some other Functor guru can
address those and either quash our fears or exacerbate them.

Again in my utopia, I would see the functionality in Functor being
incorporated into Collections as there seems to be a lot of
duplication of efforts.  May Rod can explain the reason behind the
separation.

Brent Worden
http://www.brent.worden.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message