ok
On Tue, Aug 6, 2013 at 5:17 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 8/6/13 7:27 AM, Ajo Fod wrote: > > Is this an issue then? > > Best not to top-post. Lets see if we get any other views on how the > setup may be improved. Then when we have consensus that a design > change is warranted and what that change will be, we can open a > ticket to track the work. > > Phil > > > > -Ajo > > > > > > On Fri, Aug 2, 2013 at 3:48 PM, Phil Steitz <phil.ste...@gmail.com> > wrote: > > > >> On 8/2/13 3:09 PM, Ajo Fod wrote: > >>> The class design of AbstractStorelessStats (Storeless) suggests that it > >> is > >>> storing data in its parent AbstractUnivariate (Parent) and there are > >>> methods accesible to a child of this class that shouldn't be to > something > >>> that is storeless in: > >>> > >>> private double[] storedData; > >>> > >>> ... perhaps Percentile etc should inherit from another subclass of the > >>> Parent? > >>> > >> I agree that there is no reason that > >> AbstractStorelessUnivariateStatistic should extend > >> AbstractUnivariateStatistic and the smelliness of exposing getData > >> in the child is a good reason for it *not* to. I think the > >> implemented interfaces do make sense to inherit from one another, > >> but the abstract parents should be independent. While cleaning this > >> up, I would also nuke the argumentless evaluate() from > >> AbstractUnivariateStatistic. > >> > >> Percentile in its current implementation requires the data to be > >> stored in memory, so it is not a "storeless" - i.e., it should > >> inherit as it does from AbstractUnivariateStatistic. We have been > >> talking about implementing a "storeless" approximation algorithm, > >> but that should go in a new class which would inherit from > >> AbstractStorelessUnivariateStatistic. > >> > >> There may be other reasons that I don't remember for why the > >> abstract parent inheritence is there. But those should be picked up > >> by the unit tests. Any better ideas on how to achieve what we have > >> been achieving with these classes? As I said above, as long as the > >> tests pass with only trivial mods, I am OK breaking the parent / > >> child on the abstract parents. Now is a great time to think about > >> other ways to make the code easier to understand / use. > >> > >> Phil > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
