You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2007/11/26 06:36:55 UTC
Re: [math] Release planning, IOC-friendlyness
On Sep 3, 2007 8:33 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 9/2/07, Luc Maisonobe <Lu...@free.fr> 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 https://issues.apache.org/jira/browse/MATH-160, 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.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Phil Steitz <ph...@gmail.com>.
> I agree with the DescriptiveStatistics class (except the fact the
> serialVersionUID should be uptdated). I think DescriptiveStatisticsImpl
> should be deprecated (also the import for ResizableDoubleArray that
> remains in this stripped down class is not useful anymore).
>
Thanks, Luc. I fixed these things and noticed a couple more problems.
First, the lazy initialization setup would break thread safety of
SynchronizedDescriptiveStatistics, so I eliminated that. Second, I
had neglected to modify getPercentile() to use the configured
implementation. This creates a challenge, because evaluating a
percentile is really a two argument operation. Percentile has a
setQuantile method that needs to be activated before evaluate (a sort
of smelly setup, but what we implemented in 1.0 and we have to live
with). So implementations have to support this. I am not in love
with the reflection-based approach that I took to get this to work and
am open to suggestions for how to handle this better.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz wrote:
> On Sep 3, 2007 8:33 AM, Phil Steitz <ph...@gmail.com> wrote:
>> On 9/2/07, Luc Maisonobe <Lu...@free.fr> 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 https://issues.apache.org/jira/browse/MATH-160, 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.
I agree with the DescriptiveStatistics class (except the fact the
serialVersionUID should be uptdated). I think DescriptiveStatisticsImpl
should be deprecated (also the import for ResizableDoubleArray that
remains in this stripped down class is not useful anymore).
Luc
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org