Fork me on GitHub
#clojure-spec
<
2019-04-19
>
lilactown16:04:30

I have a multi-spec for different query types to a service. I also want to dispatch on the query type to actually query the service

lilactown16:04:55

what's the best way to consolidate these two things?

lilactown17:04:52

cause atm I have:

(defmulti query-type :type)

(defmethod query-type :view/id [_]
  (s/keys :req-un [:content.query/id]))

(defmethod query-type :fragment/id [_]
  (s/keys :req-un [:content.query/id]))
and then for implementation:
(defmulti query (fn [conn q] (:type q)))

(defmethod query :view/id
  [{:keys [url]} {:keys [id]}]
  {:url (str url "/view/" id)
   :method :get
   :as :json})

(defmethod query :fragment/id
  [{:keys [url]} {:keys [id]}]
  {:url (str url "/view/" id)
   :method :get
   :as :json})
and then I need to create a wrapper function so I can fdef the implementation, right?

misha18:04:27

afaik spec does not work for multimethods, but you can declare implementation function(s), fdef it/them, and make your multimethod call it/them

lilactown21:04:21

it looks like multi-specs s/keys check all available keys, even when not specified?

lilactown21:04:29

actually not sure if this is multi-specs or s/keys doing this

seancorfield21:04:02

If you have a qualified key that matches a spec, it will be checked, whether it's specified in s/keys or not.

Alex Miller (Clojure team)21:04:18

this is documented in the s/keys docstring

lilactown21:04:39

gotcha - it's just not what I want right now šŸ˜‚

dominicm21:04:52

@alexmiller just read your inside clojure. The api seems very global for closed specs. Have you given much thought to how it might be scoped?

Alex Miller (Clojure team)21:04:08

Scope in what dimension?

Alex Miller (Clojure team)21:04:31

It is very global, like instrumentation

dominicm21:04:26

Maybe with a dynamic binding, so thread local.

dominicm22:04:23

Thinking of a web server with many concurrent requests where you want the closed spec on the boundary, but internally within processing the open spec may be used (as other sources are merged).

borkdude22:04:45

Interesting choice to turn off and on ā€œclosednessā€ for specs. Would it make sense to combine this with select somehow? Like (s/def ::closed-spec (s/select ::open-spec ...))?

Alex Miller (Clojure team)22:04:31

It should work with select too, I just havenā€™t done that yet. Thereā€™s just a lot of copied code there at the moment

borkdude22:04:14

no, I mean, turn an open spec into a closed one using select, not by a global flag

borkdude22:04:38

(then select would have to support that)

Alex Miller (Clojure team)22:04:16

Closeness is intentionally not part of the spec language and wonā€™t be

šŸ‘ 4
Alex Miller (Clojure team)22:04:23

Itā€™s part of the api

Alex Miller (Clojure team)22:04:52

@dominicm still thinking about this aspect

šŸ‘ 4
borkdude22:04:12

but when you would like to use a spec in different ways, you would have to toggle this flag all the time?

Alex Miller (Clojure team)22:04:35

Thatā€™s the aspect weā€™re think about still

borkdude22:04:18

I guess you can just make a copy of the spec, like (s/def ::foo ::bar), but if you close bar, will foo also be closed?

Alex Miller (Clojure team)22:04:31

Well thatā€™s not a copy, itā€™s an alias

dominicm22:04:39

@borkdude feels like working around the intentional limitation to make closed&open copies.

Alex Miller (Clojure team)22:04:47

The answer is tricky, and may change

dominicm22:04:03

@alexmiller btw, why the global on/off switch? My reaction was that I'm going to see someone turning it on globally unconditionally in some project and removing the upside of open specs.

Alex Miller (Clojure team)22:04:34

Do you just mean the no-arity version of close/open?

borkdude22:04:25

is s/valid? part of the spec language? why not make it an option to those functions?

Alex Miller (Clojure team)22:04:56

s/valid? is api, not spec language

borkdude22:04:18

yeah ok. I think having it as an option is more flexible than setting it globally

Alex Miller (Clojure team)22:04:36

Still might do that. Breaks all existing APIs and specs though

borkdude22:04:50

extra arity doesnā€™t break?

Alex Miller (Clojure team)22:04:01

It will break the protocol

Alex Miller (Clojure team)22:04:37

Weā€™ve also been thinking about a fast s/valid? path. Right now thatā€™s tunneled through the conform* protocol, which does a lot of useless work if just validating. So that could also be a flag, or a separate protocol method

borkdude22:04:59

(s/valid2? ā€¦) šŸ˜‰

Alex Miller (Clojure team)22:04:21

Those could all be flags internally on conform*

Alex Miller (Clojure team)22:04:40

We are already in a new namespace, no need to number

Alex Miller (Clojure team)22:04:08

But ideally could minimize breakage for some of those spec libs

Alex Miller (Clojure team)22:04:01

Anyhow, what Iā€™m interested in hearing now is how you would use it

Alex Miller (Clojure team)22:04:16

We can work out the best answers from that

borkdude22:04:24

a fast s/valid? path would certainly help things like core specs which quickly become noticable in performance

Alex Miller (Clojure team)22:04:07

Itā€™s not going to be like 10x or anything

Alex Miller (Clojure team)22:04:47

It really matters when you are constructing conformed outputs

borkdude22:04:56

I think the closedness aspect is something where people choose different tools or use workarounds for spec right now at API level things, like maybe Reitit and yada (which now uses Schema), but Iā€™ll let those maintainers chime in

Alex Miller (Clojure team)22:04:26

Like how often are you likely to use the same spec in both open and closed check modes on the same spec? And where different, is it per usage or per thread or per what?

dominicm22:04:43

@alexmiller I can imagine closed for the incoming boundary, open internally when merging additional internal data, and potentially closed again when sending it on to another consumer (e.g. A service which accepts too much or a database)

šŸ™‚ 4
ā˜ļø 4
borkdude22:04:01

thatā€™s exactly how I would use it too and probably in combination with select

dominicm22:04:18

I'm not the maintainer of yada, but I'm influential there. For incoming web requests, I'm more interested in: - not checking extra keys - not seeing extra keys

dominicm22:04:07

I don't want to throw if there's extra keys, probably, just silently drop them.

dominicm22:04:02

Sorta, but recursive :)

seancorfield22:04:29

My first reaction is: ugh, no! Mutable global state on spec behavior just feels horribly wrong. I could have a spec defined in one place and just looking at that and the uses of it no longer tells me whether extra keys are permitted or not, because any random code, anywhere in the system can toggle that setting :face_vomiting: šŸ¤Æ šŸ˜ 

seancorfield22:04:32

It seems like the absolute worst of all worlds, to be honest.

ā˜ļø 28