Hi.

On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
[...]


But overall it would be much better to put all this in a new component
and deprecate all of CL's "Random"-parameterized methods.
It was noted (not only by me) that CL grew too big (and out of its original scope). "RandomUtils" is relatively small (in Lang 3.4): now is a good opportunity to deprecate these few methods and those intended for 3.5
and redirect users to a dedicated component.

+1


[...]

Within the context of a forthcoming release of "Commons RNG" and
identified shortcomings of the random-related utilities implemented
in "Commons Lang", e.g.:
  https://issues.apache.org/jira/browse/LANG-1196
  https://issues.apache.org/jira/browse/LANG-1254
I'm proposing to ask INFRA to create a new git repository, to become
the "Commons" home of random utilities, i.e. anything that _uses_ an
"external" source of randomness (as opposed to _implementations_
of (P)RNG algorithms, which is the scope of "Commons RNG").

Examples of utilities:
 * non-uniform deviates (to be extracted from "Commons Math")
 * extended tools, such as "numbers within a range" (to be
   extracted from "Commons Lang") and "quasi-random" generators
   (to be extracted from "Commons Math"),
 * string utilities (to be extracted from "Commons Math" and
   "Commons Lang"),
 * shuffling of primitive arrays and "List<T>" (to be extracted
   from "Commons Math"),
 * bridges between alternative APIs:
     - java.util.Random
     - java.util.SplittableRandom
     - UniformRandomProvider from "Commons RNG" (to be extracted
       from "Commons Math")
     - other Java libraries
 * wrappers around "external" sources of randomness, e.g. system
   devices (UNIX) and native libraries, and interface extensions
   needed to support them (streams, IO handling, etc.).

Given the variety of the above (non-exhaustive) list, it is
foreseen that the component will be "multi-modules"[1] in order
to let users depend only on what they need for their use-case.
[For example, an engineering application could need non-uniform
deviates (e.g. Gaussian-distributed sequences), but should not
be required to depend on the (orthogonal) development of string
generators or cryptographic features.]


Regards,
Gilles

[1] Help is most welcome to set this up.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to