commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Math] Issue 348
Date Fri, 05 Mar 2010 22:06:09 GMT
On 05/03/2010, Gilles Sadowski <gilles@harfang.homelinux.org> wrote:
> Hi.
>
>
>  > >  > 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
>   https://issues.apache.org/jira/browse/MATH-349
>  you cannot always use the getters/setters, namely in contructors.

That is a separate issue.
It is possible to overload methods called by a constructor, but it is
easy to get it wrong.

>  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
>  immutability.
>  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
>  "Vector3D".]
>
>
>  > >  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?

It's precisely to keep the implementation that the parent needs to use
the getter.

If the parent does not use the getter, then the sub-class will have to
re-implement the parts of the parent code that don't use the
(overloaded) getter.

>
>  Best,
>  Gilles
>
>  ---------------------------------------------------------------------
>  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


Mime
View raw message