-
Notifications
You must be signed in to change notification settings - Fork 218
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
feat: accept vectors of size 2 in addition to MapEntry in unparse #1140
Conversation
src/malli/core.cljc
Outdated
(if-some [unparse (get unparsers (key x))] | ||
(unparse (val x)) | ||
(if-some [unparse (get unparsers (first x))] | ||
(unparse (second x)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nth
might be more equivalent in performance here since I think first
needs to go via seq
.
(def schema
[:or
[:tuple :string :keyword]
[:orn ["any" :keyword]]])
(->> (m/parse schema :any) (m/unparse schema))
; => ["any" :any] |
Ouch, that's a nice corner-case! This behaviour is the same in ;; in master
(m/validate [:tuple :string :keyword] (clojure.lang.MapEntry. "a" :a)) ; => true |
Indeed. So, to get correct behavior, we would need the record. Maybe for the |
.. but would this solve the original issue? |
(defrecord Tagged [key value])
(defn -tagged [key value] (->Tagged key value))
(defn -tagged? [x] (instance? Tagged x))
(def schema
[:or
[:tuple :string :keyword]
[:orn ["any" :keyword]]])
(->> :any (m/parse schema))
; => #malli.impl.util.Tagged{:key "any", :value :any}
(m/unparse schema *1)
; => :any
(m/unparse schema (miu/-tagged "any" :any))
; => :any I think this would solve this and no ambiguity with vectors. |
The record wouldn't fully solve the original problem (making custom inputs to unparse easy), but would at least solve the footgun (things look like vectors but aren't). I agree that the record would be the most correct solution. Re: breaking, I think it would be breaking for people who are consuming the output of |
true that. Tried to look if the parse syntax is agreed to be stable or not, no mention of that so user can assume it is, thus breaking. |
Using a MapEntry was confusing users, because it printed like a vector, but you couldn't give a vector to unparse. The current method of using MapEntry was broken for weird schemas: ``` (def schema [:or [:tuple :string :keyword] [:orn ["any" :keyword]]]) (->> (m/parse schema :any) (m/unparse schema)) ; => ["any" :any] ; should've been :any ``` Changes the parse behaviour for (at least) :orn, :altn and :multi Some place (like the entry parsers) used miu/-tagged to generate MapEntry values. These use sites now use the new miu/-entry. This keeps the surface area of this change a lot smaller since we don't need to touch all the map entry logic. fixes #1123 replaces #1140
The record solution is now available in #1150 . Closing this PR. |
Using a MapEntry was confusing users, because it printed like a vector, but you couldn't give a vector to unparse. The current method of using MapEntry was broken for weird schemas: ``` (def schema [:or [:tuple :string :keyword] [:orn ["any" :keyword]]]) (->> (m/parse schema :any) (m/unparse schema)) ; => ["any" :any] ; should've been :any ``` Changes the parse behaviour for (at least) :orn, :altn and :multi Some place (like the entry parsers) used miu/-tagged to generate MapEntry values. These use sites now use the new miu/-entry. This keeps the surface area of this change a lot smaller since we don't need to touch all the map entry logic. fixes #1123 replaces #1140
Using a MapEntry was confusing users, because it printed like a vector, but you couldn't give a vector to unparse. The current method of using MapEntry was broken for weird schemas: ``` (def schema [:or [:tuple :string :keyword] [:orn ["any" :keyword]]]) (->> (m/parse schema :any) (m/unparse schema)) ; => ["any" :any] ; should've been :any ``` Changes the parse behaviour for (at least) :orn, :altn and :multi Some place (like the entry parsers) used miu/-tagged to generate MapEntry values. These use sites now use the new miu/-entry. This keeps the surface area of this change a lot smaller since we don't need to touch all the map entry logic. fixes #1123 replaces #1140
fixes #1123