On Sat, Nov 05, 2011 at 12:29:15AM -0700, Phil Steitz wrote:
> The comments in MATH-701 included a couple of suggestions for
> refactoring RandomDataImpl.
>
> 1) Eliminate the lazy initialization of the non-secure and secure
> generators. Have the constructor initialize the generators
> instead. I am fine with this for the non-secure generator, but
> initializing a secure random generator can be quite slow, so that is
> not a good idea.
I assume that you talk about the default/no-argument constructor here.
If one of the fields ("secRand") is optional, costly to initialize, not
often used, ... those are certainly arguments to put it in its own subclass
(where it can be initialized in the constructor, and declared "final").
> 2) Split out the secure stuff into a separate class, possibly a
> subclass. I am ambivalent on this one, as I see RandomDataImpl as a
> utility class and it is convenient to have the most commonly used
> data generation utilities bundled together. The "secure" methods
> only generate hex strings, ints and longs. I have never had the
> need or heard of the need for "secure" gaussians or the other
> non-secure deviates. Has anyone else? Any comments either way on this?
+1 for separating.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
