Use existing spec-coerce library for coercions #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's my proposal to resolve #1 .
The spec-coerce library seems to me to be the most complete attempt at leveraging specs for data coercion. However, the interface is a bit more stringent than what cyrus-config has been accustomed to. Essentially,
:spec
should only be provided as a qualified keyword to a registered spec. Bare predicates (likeint?
) don't work in the way that cyrus-config has been using them in its tests and documentation.So, in addition to deleting the parsing logic from cyrus-config and using
sc/coerce!
in its place, this PR updates the tests and documentation with the required usage thereof.Personally, I see this as a positive change, as specs should almost always be registered to keywords using
s/def
anyway. So it's enforcing good code practice to an extent. Furthermore, spec-coerce's model of providing custom coercion decomplects the spec from the coercion:vs
This change is also pending a PR I made to spec-coerce.