commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [math] Release planning, IOC-friendlyness
Date Mon, 26 Nov 2007 05:36:55 GMT
On Sep 3, 2007 8:33 AM, Phil Steitz <> wrote:
> On 9/2/07, Luc Maisonobe <> wrote:
> > On 2007-05-15, Phil Steitz wrote:
> >
> > > I agree.  So, probably best is to deprecate the current abstract
> > > factories and move to single concrete factories with impl setters for
> > > IOC support.  The concrete factories exist already, so it may just be
> > > a matter of deprecation and possibly renaming some things.  Here
> > > again, we could deprecate in 1.2, remove in 2.0.  Lets step back and
> > > reexamine the overall setup and introduce a better approach. All ideas
> > > / suggestions welcome.  Consistency is important, though, so whatever
> > > we decide on, lets be consistent in distributions, solvers, etc.
> >
> > I am working on a new UnknownDistributionChiSquareTest interface
> > concerning issue, and I
> > have to find the proper way to create instances. We talk about factories
> > and deprecation, and I think there are still issues.
> >
> > I think deprecating the abstract factories and using only the concrete
> > implementations would not be wise, it seems strange to have a
> > non-deprecated class extend a deprecated one. We should better remove
> > the "abstract" qualifier and simply push the concrete code up. Then we
> > can add the setters in these single factories for IOC concerns. The
> > current XxxFactoryImpl classes would then become empty and would be
> > deprecated. Does this seem sensible to everybody ?
> >

Sorry for the delay in getting back to this.  I just committed
(r598133) an attempt at this for DescriptiveStatistics /
DescriptiveStatisticsImpl.  Pls any [math] or other interested parties
have a look.  I can roll it back if there are objections or better
ideas.  Clirr complained about removing fields from the now deprecated
subclass, but these are protected in the parent, so I don't see this
as an issue.  I took care to keep the argumentless constructor in
DescriptiveStatistics empty so it would not cause problems for
subclasses (we have an example in ListUnivariateImpl in /test) and I
can't think of other compatability issues.  It is quite possible that
clirr and I are both missing something, though, so I would appreciate
a careful look.

If all are OK with this approach, I will do the same thing for
SummaryStatistics / impl.


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

View raw message