commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Mon, 02 Jan 2017 14:32:39 GMT
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 <sebbaz@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 <gilles@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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


Mime
View raw message