commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Fri, 30 Dec 2016 18:11:00 GMT
On Fri, 30 Dec 2016 17:30:17 +0000 (UTC), Bernd Eckenfels wrote:
> Sorry I meant *uniform* distribution
>
> Gruss
> Bernd
>
>
>
>
>
> On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels"
> <ecki@zusammenkunft.net> wrote:
>
>
>
>
>
>
>
>
>
>
> Hello,
> I am somewhat unclear, why would you require a random distribution
> (Interface).

Who said?

> Is there no better more generic Interface in RNG-API?

Have you had a look at
   
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
?

> Having said that I still think j.u.Random is fine

Have you read
   
http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
?

Why use a poor algorithm when using a better one is as easy?

> - but if not maybe a
> byte or int Provider would be better than a specific interface for 
> the
> random source.

I don't follow.
How do you define this "Provider" if not with an interface?

Gilles

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible"
> <joerg.schaible@gmx.de> wrote:
>
>
>
>
>
>
>
>
>
>
> Gilles wrote:
>
>> Hi.
>>
>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>>> Hello all,
>>>
>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>>> tickets before proceeding with the release, but I wanted to check 
>>> to
>>> see if anyone else has any opinions on what work needs to be
>>> completed
>>> before the release.
>>>
>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>>> indifferent here, I just want some other’s to weigh in as to their
>>> thoughts before deciding to leave in the dependency
>>
>> I don't follow.
>> Currently, there is no dependency towards RNG.
>>
>> Personally, I'm in favour of an API that "advertizes" and recommends
>> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
>> high-level component (and it already depends on [LANG]).]
>>
>> However a consensual proposal would be to define a custom interface
>> (see JIRA discussion), and define the API around it.
>>
>> [TEXT] should be made "multimodule"; it could then provide bridges
>> (cf. JIRA comment) in separate modules:
>>
>>   * commons-text-core (algos)
>>   * commons-text-commons-rng-bridge (from
>> "o.a.c.rng.UniformRandomProvider")
>>   * commons-text-jdk-bridge (from "java.util.Random")
>>
>> The dependency towards Commons RNG thus becomes optional.
>> But application developers have to explicitly choose an
>> implementation (which is good).
>
> You can achieve something similar by declaring commons-rng as 
> optional. If
> you introduce an API for the random functionality and one 
> implementation is
> based on commons-rng, any user will have to declare this dependency 
> on his
> own if he like to use this implementation.
>
> We have a similar setup in vfs where you have to declare jsch as 
> dependency
> on your own if you want SSH support for the protocol in use.
>
>>> and making more
>>> progress on the best pattern after the 1.0 release.
>>
>> API decisions must be made before a major release.
>>
>> The best pattern is the above (IMHO, and as per Jochen's note):
>> higher flexibility and higher correctness.
>
> Cheers,
> Jörg
>


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


Mime
View raw message