commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (Commented) (JIRA)" <>
Subject [jira] [Commented] (MATH-758) Fields which could be private and/or final
Date Sat, 03 Mar 2012 01:38:38 GMT


Sebb commented on MATH-758:

LaguerreSolver.complexSolver - could this be private and final?

Dfp fields exp/mant/nans/sign - looks like these could be private with getters, apart from
nans which is written by subclasses.

AbstractFormat.setNumeratorFormat() - are these needed (only used in test code)? If not, the
underlying fields could be made final

NordsieckStepInterpolator.stateVariation is only used internally AFAICT, so could be private

FirstMoment.n has a getter, and is not updated externally, so could be private
FourthMoment.m4 is only read externally by Kurtosis, so could be private (there is a getter)
The fields m1, m2, m3 are only ever written by the xxxMoment classes, which set them to zero.
Each class could have a protected zero() method, which could be chained in the same way as
the clear() method.
Other classes could then use the getters and m1-m4 could be private.

[To be continued]

> Fields which could be private and/or final
> ------------------------------------------
>                 Key: MATH-758
>                 URL:
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Sebb
> BaseAbstractUnivariateIntegrator has several fields that are not currently changed after
construction and could be final:
> protected double absoluteAccuracy;
> protected double relativeAccuracy;
> protected int minimalIterationCount;
> protected Incrementor iterations;
> protected Incrementor evaluations;
> These all have getters as well, so could also be made private.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message