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.
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))
; => :anyI 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