The job of TEXT is to use the provided random source to generate the text output. TEXT should make it easy to use any implementation that provides the range of input values it needs. The choice of random source is up to the user; they are the only ones who know what sort of randomness is needed.
The traditional way to provide the source would be to use an interface, but this is unfortunately lacking. There seem to be two ways round this: - use j.u.Random instead - define a new interface and provide bridge code Both have disadvantages. I'm wondering if a reflection-based approach would be better? e.g. the user has to provide an instance of the class containing the method(s) needed by TEXT. This is effectively an implicit interface defined by the code. So it can be applied to any existing implementation that already provides the method(s). Obviously this also has some disadvantages, but could eliminate the need for bridge code. The method name(s) could be user-defined to cover the case where different random impls used different names for the same functionality. On 31 December 2016 at 18:38, Gilles <gil...@harfang.homelinux.org> wrote: > On Sat, 31 Dec 2016 12:01:34 -0500, Rob Tompkins wrote: >> >> Based on all the discussion and that RNG isn’t currently included in >> the pom, this feels like a great 1.1 forward topic because . > > > [...] because ... ? > >> I’m going >> to mark the Jira as 1.X as opposed to 1.0. > > > Wrt the issue of providing different sources of randomness, I > had reached the conclusion that Jörg's proposal was the common > (or, perhaps, majority) ground. > [Hence, that the custom interface and bridges would be implemented.] > >> Regarding getting this in, like I said before I’m indifferent. > > > If I may insist ;-), we should be wary to provide a functionality > whose applications are unknown, and could thus be crippled in a > way extremely difficult to pinpoint, due to the fact which Bernd > emphasized a couple of posts ago: > >>>>> In a lot of situations people will be happy with j.u.R > > > IOW, by their nature, applications that use RNGs could look like > they work properly even when they don't. > > I don't know whether applications of [TEXT] could be subject to > a bug caused by some RNG weakness, but since no technical (i.e. > Java-centric) argument seems convincing for this audience, I'll > suggest that you listen to the voice of experts, by reading just > the first two paragraphs of the last section of this document > (titled "Recommendations"): > http://www.colostate.edu/~pburns/monte/rngreport.pdf > >> I >> think though that this fits into the RERO area. Also, if we feel that >> releasing with “RandomStringGenerator” in place restricts this >> conversation too much. I’m ok with removing it and going out in a >> later release with it in once we are settled on what it’s API should >> be. > > > That seems a reasonable thing to do. > The more so that I'm suspicious of the Javadoc saying that > "RandomStringBuilder [...] instances are immutable and > thread-safe". > But that's another issue. > > > Regards (and Happy New Year), > 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
