You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2017/01/02 13:31:37 UTC
Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
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 <gi...@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
Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Posted by sebb <se...@gmail.com>.
On 2 January 2017 at 14:32, Rob Tompkins <ch...@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 <se...@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 <gi...@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
Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Posted by Gary Gregory <ga...@gmail.com>.
On Jan 2, 2017 6:32 AM, "Rob Tompkins" <ch...@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?
Sounds great.
I'd rather we focus on getting all the right stringy wordy stuff "moved"
from LANG to TEXT for 1.0. Then RERO! We have momentum now. I do not see
the need for a bigger bang 1.0 for TEXT. We can add random code for 1.1.
That sounds like a perfectly reasonable roadmap.
Gary
Cheers,
-Rob
> On Jan 2, 2017, at 8:31 AM, sebb <se...@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 <gi...@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
Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Posted by Rob Tompkins <ch...@gmail.com>.
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 <se...@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 <gi...@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