Skip to content

Troubles with spec's coercion #1

Description

@WhittlesJr

I'm really liking this library, but I ran into a minor roadblock.

Consider an s/or spec being given for the :spec of a cfg/def. Assuming the configured value is valid for the spec, the "coerced" value becomes a vector with the s/or key first and the actual value second:

(s/def ::transport #{:ip :serial})
(s/def ::transport-cfg (s/or :enabled  ::transport
                             :disabled #{:disabled}))

(cfg/def MODBUS_TRANSPORT
  {:doc      "Transport layer to use for Modbus."
   :spec     (cfgc/from-edn ::transport-cfg)})

(::transport comes from a different namespace IRL, hence the separation.)

In this case, if MODBUS_TRANSPORT is set to ":ip", the coerced value becomes [:enabled :ip].

Other than creating a second var like below, I can't think of any good way around this:

(def modbus-transport (some-> MODBUS_TRANSPORT second))

This doesn't strike me as a very clean solution. Ideally, I'd want to be able to specify a coercion function separately from the :spec, and have that function alone run against the raw value. Then the spec would be only used for validation, and our values would not be polluted by spec's rather odd habit of sometimes conforming values to non-valid outputs (as in this case.)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions