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