commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Mon, 02 Jan 2017 15:03:15 GMT
On 2 January 2017 at 14:32, Rob Tompkins <chtompki@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 <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
>

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


Mime
View raw message