@ikitommi what is the difference between :title and :description in spec? I want to describe my config file using malli and guessing what should I use to describe every field in the config map.

(def http-server-host [:and {:title "http server host"} ne-string])
;; or
(def http-server-host [:and {:description "http server host"} ne-string])

@mike1452 those are pulled from JSON Schema convention: > The `title` and `description` keywords must be strings. A “title” will preferably be short, whereas a “description” will provide a more lengthy explanation about the purpose of the data described by the schema. I would use :description there. In OpenAPI & Swagger, title is pulled as the Schema name, e.g.

[:map {:title "User", :description "Describes User of the System"} 
 [:name {:description "Name of the User"} :string] 
 [:age {:description "Age, must be >= 18} [:int {:min 18}]]]

Thank you.

pulling the return types too:

(-var-schema #'str)
;[:function
; [:=> :catn :string]
; [:=> [:catn [x :any]] :string]
; [:=> [:catn [x :any] [ys [:+ :any]]] :string]]

(-var-schema #'distinct?)
;[:function
; [:=> [:catn [x :any]] :boolean]
; [:=> [:catn [x :any] [y :any]] :boolean]
; [:=> [:catn [x :any] [y :any] [more [:+ :any]]] :boolean]]

Clever:

user=> (meta (second (:arglists (meta #'str))))
{:tag java.lang.String}

Noticed too that the hand-written arglists seem to have weird syntax.

loving malli so far! what's the idiomatic way of "extending" a schema? for example let's say i have a Person map with the basic attributes first-name and last-name, and then a ProfessionalPerson that is a Person with an additional required profession attribute. would i create a ProfessionalPerson definition that contains only just [:map [:profession string]] and then mu/merge it on top of the Person map [:map [:first-name string?][:last-name-string?]]?

@joshkh Or mu/assoc

cool, thanks borkdude. on a side note it's too bad that mu/assoc doesn't allow for & kvs like clojure.core/assoc 😄

;)

Might be possible to implement. The options parameter makes it a bit inconvenient though, we could check that if odd number of params, last param is the options, and for even number of params, no options, just kv pairs. Not sure if worth the complexity.

malli.util/dissoc also takes just one key.

if you need more than one k/v, you can just use mu/merge :)

or repeat mu/assoc

yeah, merge is fine by me. i just thought it was funny that my first instinct was to treat it like the assoc i know.

Yeah. Though I think it will be worth to mention the differences to clojure.core functions in the docstrings, now the util fns mention just "like clojure.core/x" but then many of them take a bit different parameters.

perhaps. admittedly i just tried it out while completely ignoring the very clear docstring params in my editor. you can lead a horse to water but you can't make it drink 😉

It's awesome that you can do this with malli btw.

absolutely. and the deep merging is really handy, too

there are at least two options to resolve the malli.util varargs issue: 1. make all utilities only work with Schema instances, e.g. no auto-coercion from schema AST => only place to pass the options would be the m/schema -> simpler, more boilerplate, 2. make a custom type/record/protocol for the options, could be the first argument in all functions, “the schema context” - easy to distinguish it from other args

do I need to have sci for a spec like this?

[:map {:gen/fmap 'map->Point}
       [:lat [:double {:min -180.0 :max 180}]] 
       [:long [:double {:min -180.0 :max 180}]]]]

seems like it according to the tests: https://github.com/metosin/malli/blob/master/test/malli/generator_test.cljc#L94-L105

can you configure malli to use the clojure compiler for eval instead of sci?

I can’t get this to work with or without sci, can you not use namespace-qualified functions as arguments to :gen/fmap? :thinking_face:

yes, just don't quote and it works

(but, can't be deserialized if it's a fn value)

If you wan't eval, PR welcome. Could be option :malli.core/evaluator a, there could be a -eval-evaualuator in malli.core

ahh, I was fooled by the output of my REPL, it printed the record as a plain map (and skipped the record type)!

then all is well, thanks for the help 🙂