Open josephbuchma opened 7 months ago
I would love to explore these ideas.
My initial thought was to avoid the MasterOfx
pattern (I don't like it, ;-)) TBH, I'm biased because I'm not doing a lot of combinatorial testing lately, so I'm not bothered by the type assertion thing. Anyway, I'm open to any improvements in the dev experience of the library.
(Fun fact: in the PHP version you can type hint the params of the wrapper function, so you don't need to worry about casting or assert them. I discover this by chance.).
The toGoldenMasterFn
approach looks interesting for me, and I think it's more aligned with the original design. Very clever.
Anyway, I think that both approaches can be introduced in parallel and live together with the existing API. So, I would like to start playing with them.
Thank you!
Is your feature request related to a problem? Please describe. Type assertions are annoying.
Describe the solution you'd like Make things more statically typed & easier to use. Also reduce number of places to change when you add/remove/change parameters.
Describe alternatives you've considered I'm using this helper function which does type assertions for me. Would be nice to have something like that built into the library:
Additional context Another option, maybe even better one - have a set of generic functions for accepting N generic paramters, like:
This looks a bit goofy, but in practice it's not that bad - similar pattern is widely used in Elm, for example, and it's just fine https://package.elm-lang.org/packages/elm/json/latest/Json-Decode#map
With this approach, example above could look like:
Which is a bit cleaner, and in addition to that you can't swap parameters of different types by accident.