Closed cemerick closed 11 years ago
Protocol changed as of 46359bdbf778420ea003cfb52ba04bc0d4c09e06.
Looking ahead, it seems like arbitrary implies "fully random", as opposed to other generation strategies that might be geometric or weighted in nature. Does that mean that Generator will end up growing more methods?
You should be able to create any distribution you want with the generator.
FWIW, this is more an experience report + continuation of prior conversation than actual bug.
I've found the
Generator
protocol to be a bit of a PITA to use. I understand the utility and purpose of having each generator paired with its concomitant shrinker, but keep running into some semantic and practical issues:shrink-number
fn (similar tohalfs
but it works with decimals as well as integers), which I want to use to shrink all numeric values, regardless of their concrete type or method of generation (i.e. random vs. weighted, etc). My options of pairing it up with them aren't really very good though: delegate from a reifiedGenerator
, or come up with a dummy type to which I canextend
Generator
with a map of functions. This seems like busywork, esp. if I'm aiming to reuse existing value-generating facilities.arbitrary
, andshrink
is tacked on simply because shrinkers need to be paired with generators. Perhaps this is nomenclature borrowed from Haskell's quickcheck?arbitrary
implies "fully random", as opposed to other generation strategies that might be geometric or weighted in nature. Does that mean thatGenerator
will end up growing more methods?To be clear, none of this prevents me from using simple-check, but it doesn't help me look forward to writing a new
Generator
. :-)Without being familiar with quickcheck's nomenclature and background, it seems like each "parameter specification" provided to
quick-check
could just be a map with two slots,:generator
and:shrinker
, without complicating the implementation details of the lib particularly much.