Regarding Gilles’ last comment asking on why I think we should hold off on putting this functionality in. It seems that we have a lively bit of discourse here over the different varieties of offering the consumer the best options as to how to provide a uniform randomness generator to TEXT. Thus I’m going to plan on doing a 1.1 release shortly following 1.0 that is dedicated to this work. Does anyone have any objections to that?
Cheers, -Rob > On Jan 2, 2017, at 8:31 AM, sebb <seb...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
