-
Notifications
You must be signed in to change notification settings - Fork 216
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
Use custom Tag / Tags records (instead of MapEntry / Map) in parse output #1150
Conversation
Oh bother, the ordering of malli.destructure schemas is now different on clj and cljs. I'll fix the test. |
c395b5d
to
a446df9
Compare
Looks Good. Parse docs/examples should be changed too, e.g. in README: (m/parse
[:* [:catn
[:prop string?]
[:val [:altn
[:s string?]
[:b boolean?]]]]]
["-server" "foo" "-verbose" true "-user" "joe"])
;[{:prop "-server", :val #malli.impl.util.Tagged{:key :s, :value "foo"}}
; {:prop "-verbose", :val #malli.impl.util.Tagged{:key :b, :value true}}
; {:prop "-user", :val #malli.impl.util.Tagged{:key :s, :value "joe"}}] |
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.
please update docs too.
see also #1153 |
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
This avoids a problem where the map output from :catn could be confused with an actual map value. For example: ``` (def Schema [:or [:vector [:map [:s :string] [:a :any]]] [:* [:catn [:s :string] [:a :any]]]]) (m/parse Schema ["kikka" {:a 1}]) ; => [{:s "kikka", :a {:a 1}}] (m/unparse Schema *1) ; => [{:s "kikka", :a {:a 1}}] ; should've been the original value, ["kikka" {:a 1}] ``` fixes #1153
a446df9
to
43acc12
Compare
still need to update the docs, will try to do that tomorrow |
... and rename Tagged to Tag
43acc12
to
9a1ba56
Compare
9a1ba56
to
5e3d6b4
Compare
Ready for review/merge now IMO. |
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.
Beautiful. Predicates like map?
might still cause parse confusion, but such is life. Is :multi
effected?
Yeah, |
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:
Changes the parse behaviour for (at least) :orn, :altn and :multi
For similar reasons, also use a new Tags record, instead of a map, for :catn
parse results. See #1153.
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 #1153 replaces #1140