On 03/05/2019 13:04, Gilles Sadowski wrote:
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".
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
