Currently, increasing verbosity via hooks involves some dataflow that is more complicated than necessary - passing a void*-cast environment through a couple layers. It's confusing.
Adding the opaque struct theft *t handle as a first argument to the property function and
a theft_get_hook_env function to the API would simplify things significantly -- verbosity
and other flags could be stored in the same environment used by the hook functions,
and the property test could use that for saving/reporting test failure details.
Similarly, a function to copy a theft_type_info struct with a custom env would reduce
boilerplate, in cases where something like a custom limit is used. This sort of exists
already for built-in generators, but is more widely applicable.
This would also allow further random number generation (and, I guess, changing the output stream) from within a property test, so make sure the RNG seed is tracked when running the test.
Currently, increasing verbosity via hooks involves some dataflow that is more complicated than necessary - passing a void*-cast environment through a couple layers. It's confusing.
Adding the opaque
struct theft *t
handle as a first argument to the property function and atheft_get_hook_env
function to the API would simplify things significantly -- verbosity and other flags could be stored in the same environment used by the hook functions, and the property test could use that for saving/reporting test failure details.Similarly, a function to copy a
theft_type_info
struct with a custom env would reduce boilerplate, in cases where something like a custom limit is used. This sort of exists already for built-in generators, but is more widely applicable.