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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
