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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
