commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Issue 348
Date Fri, 05 Mar 2010 21:56:09 GMT

> >  > I don't see any changes proposed.
> >
> >
> > I propose to use the instance variable in place of the accessor.
> >
> >
> >  > I see a couple of statements that getters are used (usually considered
> >  > good), and a question about over-riding.
> >
> >
> > Getters are for accessing to encapsulated data. Within the class itself the
> >  data is readily accessible, so using the accessor is, at best, less
> >  efficient.
> Not necessarily - if it turns out that the field needs to be
> synchronized, then always using the getter/setter rather than direct
> access makes it very easy to fix the problem.

As I note in
you cannot always use the getters/setters, namely in contructors.

I don't have a broad view of CM yet, but in principle I'd think it's better
to avoid synchronization at the CM level, and rather push toward
E.g. do we loose performance significantly if we have to instantiate a new
"NormalDistributionImpl" for each combination of "mean" and "sigma" instead
of calling "setMean(m)" and "setStandardDeviation(s)" on an exisitng object?
[A few months ago, people here convinced me that we don't, in the case of

> >  Moreover, if, by mistake, a sub-class overrides the accessor, you can get
> >  inconsistent result: the overridden accessor can return some value while it
> >  is another (the one stored in the instance variable) that is used to perform
> >  the calculation.
> If there is a good reason to override the getter/setter, then it is
> likely that the sub-class wants the new value to be used throughout.

Can you imagine a not contrived example? I.e. why would one inherit from a
class while throwing away the implementation?


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

View raw message