-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
speced/get-in #48
Comments
Interesting feature!
I don't agree, it also deviates from |
Thanks for the feedback!
quite obviously I'm aware of this. A core idea of speced.def (or clojure.spec in general?) is that a given app has a specific schema and that it should be honored, with fail-fast behavior when that premise is broken.
let's say that after a schema change, Now something fails, possibly in another ns, or even a different project. How do you debug it? Fail-fast behavior points right at the culprit instead of making you go in a bug hunt from defn to defn / from ns to ns. |
I see, but aren't I was thinking about allowing the consumer to specify specs on keys in the get-in vector; but metadata can't be applied to to keywords/numbers so that wouldn't work 🤔 |
They are not more appropiate for the precise stated reason: their error reports can happen arbitrarily later (and farther away) than the actual source of the error. To put it in another POV: when you refactor shapes in a codebase, you often have to refactor
Not sure of how destructuring is related to the topic |
(speced/get-in {:foo 2} [:foo :bar :baz])
=> error message explaining that2
does not contain :bar(speced/get-in {:foo {:bar {}}} [:foo :bar :baz] ::default)
=> ::default(speced/get-in {:foo 2} [:foo :bar :baz] ::default)
=> error message explaining that2
does not contain :barThe latter behavior is interesting. Fallback values should only be offered if the last member of the chain was missing, but not for intermediate values.
Essentially it ensures the structure is as expressed.
The text was updated successfully, but these errors were encountered: