commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <>
Subject Re: [math] Moving apply() down DescriptiveStats hierarchy, simplifying structure
Date Tue, 27 Jan 2004 00:02:01 GMT

On Sun, 25 Jan 2004, Mark R. Diggory wrote:

> Phil Steitz wrote:
> > The tests and javadoc still need work.  I also notice that the BeanList
> > stuff has been moved to /test.  Are we thinking about eliminating this?
> Not really intending to get rid of it, It was more just to maintain
> BeanListUnivariateImpl (now completely misnamed) as an example of an
> implementation and a good test, without having to force maintaining it
> as part of the API. I still have issues with its design.
> > One thing that I thought about which would provide most of the value of
> > these classes would be to just add a factory somewhere (maybe StatUtils)
> > that would create a DescriptiveStatistics instance from a collection and
> > a property name.
> I think the real nagging issue that pushed all this into test was the
> fact that you can wrap a collection inside of the BeanListUnivariateImpl
> but there was no solution to maintaining state on changes in the
> underlying Collection, which makes it a requirement that everytime a
> statistic is calculated, all the Collection entries need to be
> "Transformed" (over and over again).
> I guess the big question is... Is there a way to listen for changes in
> the underlying collection while still using the java.util.collection api?

Yes, the sandbox [event] project contains the observed/observable
collection packages removed from [collections] HEAD before the 3.0

There are a couple of alternate designs yet to be merged so-to-speak into
the [event] codebase, at




I imagine now that [collections] 3.0 has been released some further
progress will be made in [event].


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message