commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] Issue 348
Date Sat, 06 Mar 2010 15:32:08 GMT
Gilles Sadowski 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.
> 
> 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".]

This is a separate issue, as you point out.  I am +1 on deprecating
the setters so these all become immutable in 3.0.

Phil
> 
>>>  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
> 


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


Mime
View raw message