-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QCheck2.Gen
design considerations
#162
Comments
Ah, I forgot: Additional
|
Optional parametersIn my opinion, whenever it makes sense, we should provide a generator that does not take any additional input (make it dead-easy to get started on QCheck) so I'd go with Then we should also provide another function that takes a mandatory - labeled or not, this depends if there are other arguments - generator. I guess there's no choice but to provide this second one with a different name 🤷 Generator namesYes, yes, yes, please, the naming inconsistencies have driven me crazy many times in the past, and it remains a barrier for newcomers 🙏
Use of underscore in name suffixesI am all in on using the Additional char/string generatorsSure, why not |
fwiw I'm all for new, more consistent names, especially in |
I totally agree with you too (especially with the generator names). |
In addition to what has already been said, I propose the inclusion of val small_string : string t
val small_string_of : char t -> string t (or with |
With
QCheck2
still not yet released (and still being tested) we have a brief opportunity to discuss the design of itsGen
combinators.Optional parameters
We have had problems with optional parameters in the past (see #75). These may cause problems when they are the only parameters. For QCheck this could usually be solved with type annotations:
For
Check2
however becauseQCheck2.Gen.t
is opaque, even with the fix in PR #161, the type annotation trick doesn't work anymore:Effectively, this means the (labeled) parameter is required, not optional.
As such, we should seriously consider changing
QCheck2.Gen.small_string
to one of the following:Of the three above, I would prefer one of the first two.
Based on our choice, we should consider whether to update
string_size
accordingly following the principle of least surprise:Looking at the
Gen
module's signature I can see a similar problem withGen.pint : ?origin:int -> int t
which we also need to address:Here, we probably should go with a regular or labelled argument. Again, from the principle of least surprise,
we should consider updating the remaining
origin
-taking combinators to take the same kind oforigin
argument:Besides the
Gen.generate*
bindings, only two bindings now stand a bit out:I think for
opt
the use of an optional parameter is warranted.For
make_primitive
we may consider whether labelled arguments are needed.Generator names:
Naming-wise, we should consider the consistency. Here are the string generators:
Wouldn't
string_small
be nice and consistent - and easier to find using tab-completion?I think the same goes for the list generators (
small_list
->list_small
):and the array generators (
small_array
->array_small
):For
int*
,float
, andchar
generators it is harder...Use of underscore in name suffixes
I spotted an unfortunate variation in the use of
_l
,_a
orl
,a
suffixes:I know a lot of this is legacy, but with a clean
QCheck2
now is a good time to consider cleaning these things a bit up.The text was updated successfully, but these errors were encountered: