commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Herbert <alex.d.herb...@gmail.com>
Subject Re: [rng] Split and Jump functions
Date Fri, 03 May 2019 12:55:34 GMT

On 03/05/2019 13:04, Gilles Sadowski wrote:
> Hello.
>
> Le jeu. 2 mai 2019 à 23:49, Alex Herbert <alex.d.herbert@gmail.com> a écrit :
>>
>>
>>> On 1 May 2019, at 23:15, Gilles Sadowski <gilleseran@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>>>> [...]
>>>> So do we do:
>>>>
>>>> UniformRandomProvider restrict(JumpableUniformRandomProvider);
>>>> JumpableUniformRandomProvider restrict(LongJumpableUniformRandomProvider);
>>>> UniformRandomProvider restrict(RestorableUniformRandomProvider);
>>>>
>>>> Or:
>>>>
>>>> UniformRandomProvider unjumpable(JumpableUniformRandomProvider);
>>>> JumpableUniformRandomProvider unlongJumpable(LongJumpableUniformRandomProvider);
>>> I'm a bit hesitant on the spelling…
>> Do you mean unlongJumpable vs unLongJumpable vs unlongjumpable? In that regard I
was maintaining the likeness to unrestorable, but since there are two words after 'un' I put
the second with camelcase.
> I had noticed that the consistent name would be "unlongJumpable" but
> "unlong" just looks like a typo. :-{
>> Or just the entire method name? I don’t like it much but its function is clear:
allow access to jump() but not longJump().
> Shall we just leave out those convenience methods until there is an
> explicit need?  As discussed previously, it doesn't seem to me that
> the added safety is not as useful as for "unrestorable".

OK. Seems reasonable.

Note that 'unjumpable' would apply to either Jumpable or LongJumpable. 
However as you state it is easiest to not have them to begin with.

>
> Regards,
> Gilles
>
>>>> UniformRandomProvider unrestorable(RestorableUniformRandomProvider);
>>>>
>>>> The later option only adds two new methods. The first has 3 new methods (deprecating
unrestorable with restrict) but suffers from having to cast instances of multiple interfaces
to ensure the correct restrict is called.
>>> Oops indeed.
>>> This is too error-prone.
>>>
>>>> So this makes me favour the verbosely named option.
>>> +1
>>>
>>> Regards,
>>> Gilles
>>>
>>>> Alex
> ---------------------------------------------------------------------
> 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