commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gillese...@gmail.com>
Subject Re: [rng] Split and Jump functions
Date Fri, 03 May 2019 12:04:45 GMT
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".

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


Mime
View raw message