Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 5 Mar 2010 22:56:09 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [Math] Issue 348
Message-ID: <20100305215609.GC6536@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20100305123427.GD31457@dusk.harfang.homelinux.org>
 <c7d45fc71003050916o31be0a87lf0cc64471102175c@mail.gmail.com>
 <20100305183716.GB6536@dusk.harfang.homelinux.org>
 <25aac9fc1003051258t521498d0v409f2b7224cfa4ee@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25aac9fc1003051258t521498d0v409f2b7224cfa4ee@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: eir 20002; Body=1 Fuz1=1 Fuz2=1

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.

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?


Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org