Hello, I am somewhat unclear, why would you require a random distribution (Interface). Is there no better more generic Interface in RNG-API? Having said that I still think j.u.Random is fine - but if not maybe a byte or int Provider would be better than a specific interface for the random source.
Gruss Bernd -- http://bernd.eckenfels.net On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible" <joerg.schai...@gmx.de> wrote: Gilles wrote: > Hi. > > On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote: >> Hello all, >> >> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira >> tickets before proceeding with the release, but I wanted to check to >> see if anyone else has any opinions on what work needs to be >> completed >> before the release. >> >> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively >> indifferent here, I just want some other’s to weigh in as to their >> thoughts before deciding to leave in the dependency > > I don't follow. > Currently, there is no dependency towards RNG. > > Personally, I'm in favour of an API that "advertizes" and recommends > usage of its RNG sibling component. [As [TEXT] is, admittedly, a > high-level component (and it already depends on [LANG]).] > > However a consensual proposal would be to define a custom interface > (see JIRA discussion), and define the API around it. > > [TEXT] should be made "multimodule"; it could then provide bridges > (cf. JIRA comment) in separate modules: > > * commons-text-core (algos) > * commons-text-commons-rng-bridge (from > "o.a.c.rng.UniformRandomProvider") > * commons-text-jdk-bridge (from "java.util.Random") > > The dependency towards Commons RNG thus becomes optional. > But application developers have to explicitly choose an > implementation (which is good). You can achieve something similar by declaring commons-rng as optional. If you introduce an API for the random functionality and one implementation is based on commons-rng, any user will have to declare this dependency on his own if he like to use this implementation. We have a similar setup in vfs where you have to declare jsch as dependency on your own if you want SSH support for the protocol in use. >> and making more >> progress on the best pattern after the 1.0 release. > > API decisions must be made before a major release. > > The best pattern is the above (IMHO, and as per Jochen's note): > higher flexibility and higher correctness. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
