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
|