On 05/03/2010, Gilles Sadowski <gil...@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-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
