On 2 January 2017 at 14:32, Rob Tompkins <chtom...@gmail.com> wrote: > 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?
OK by me. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
