WIP: delay/future/promise schemas#1171
Conversation
| (is (nil? (m/explain [:delay :int] (doto (delay 1) deref)))) | ||
| (is (nil? (m/explain [:delay {:force true} :int] (delay 1))))) | ||
| (testing "schema does not match delay" | ||
| (is (m/validate [:delay :boolean] (delay 1))) |
There was a problem hiding this comment.
This seems a bit off: it should fail right?
There was a problem hiding this comment.
The main decision here is whether we should force delays during validation. Given that they often contain blocking code, it might not be the best idea. Here, I thought I'd make the default to only check if realized, and allow the user to tell malli when it's ok to force the delay via a property.
frenchy64
changed the title
| (is (m/explain [:promise :boolean] (doto (promise) (deliver 1)))) | ||
| (is (m/explain [:promise {:force true} :boolean] (doto (promise) (deliver 1)))) | ||
| (is (m/explain [:promise {:force true} :boolean] (doto (promise) (deliver 1)))) | ||
| (is (m/explain [:promise :boolean] 1))))) |
There was a problem hiding this comment.
consider adding tests for get-in / walk behaviour, there's been some bugs recently in those
| :re-transformer (fn [_ children] (apply re/alt-transformer children)) | ||
| :re-min-max (fn [_ children] (reduce -re-alt-min-max {:max 0} (-vmap last children)))})}) | ||
|
|
||
| (defn -deref-schema [{:keys [type]}] |
There was a problem hiding this comment.
I understand the naming, but I fear confusion with m/deref. Not sure what to do about that. Docstring?
There was a problem hiding this comment.
My original intention for this name was to have an overarching [:deref S] schema. I couldn't decide whether it should be a simple reify or a disjunction of :delay/:promise/:future.
I'm not sure if providing a schema called :deref increases or reduces clarity here.
|
nice and orthogonal addition to the lib otherwise, love it |
frenchy64
changed the title
3 participants
https://clojurians.slack.com/archives/CLDK6MFMK/p1741110236353429
TODO
:deref