Strict conversion functions?

[gfredericks]

I personally rather like bijections more than coercions.

E.g., if I have a web API that is supposed to accept snake case query params and I use ->kebab-case to translate them to the codebase's internal format, then what I really have is an API that accepts snake case and kebab case and arbitrary combinations of the two. And this bothers me a bit.

Would it be welcome to add functions to this library that convert from one format to another and perhaps throw exceptions if the input is not in the expected format?

Problems

• n² new functions, which is a lot
• is this even well defined enough to implement reliably?

[qerub]

I share your sentiments and have been thinking about revising the API to take this shape:

(convert input :to kebab-case)
;; best-effort coercion of input

(convert input :from snake_case :to kebab-case)
;; throws exception if input is not snake_case

kebab-case
;; => {:splitter  …fn of String => [String]…
;;     :joiner    …fn of [String] => String…
;;     :validator …fn of String => boolean…}

What do you think? It avoids the n² problem nicely.

Perhaps also:

((convert :from snake_case :to kebab-case) input)
;; convert function can be partially applied

[gfredericks]

This definitely addresses my concerns. I can't think of any improvements.

[tendant]

I am trying to use this library exactly the same way. With the improved API, the result is much more predictable.

It is better to have more functions with predictable result, than just a few functions with some unpredictable corner cases.