Hello.
Le jeu. 2 mai 2019 à 23:49, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
>
> > On 1 May 2019, at 23:15, Gilles Sadowski <gillese...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
