This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-21
Channels
- # adventofcode (47)
- # aleph (18)
- # announcements (20)
- # babashka (81)
- # beginners (23)
- # biff (6)
- # calva (5)
- # cider (50)
- # clojure (34)
- # clojure-europe (19)
- # clojure-norway (11)
- # clojure-spec (6)
- # clojure-uk (1)
- # clojurescript (2)
- # conjure (2)
- # cursive (14)
- # datomic (1)
- # humbleui (11)
- # hyperfiddle (3)
- # introduce-yourself (5)
- # joyride (1)
- # nbb (7)
- # off-topic (19)
- # podcasts-discuss (1)
- # reagent (3)
- # reitit (19)
- # releases (1)
- # ring-swagger (1)
- # shadow-cljs (29)
- # sql (6)
- # squint (56)
https://clojure.org/guides/spec#_entity_maps says: > Also note that ALL attributes are checked via keys, not just those listed in the :req and :opt keys. I'm curious, does this behavior also exist in spec2? (I never invested time in spec2 at all as it's still wip)
The broader question that prompted me to ask this is: is such behavior a universally good idea? I have no opinion from my side. I don't recall it ever bothering me. Perhaps there's the performance/security consideration of checking unforeseen keys? I wouldn't mind about that either given that I can remove extraneous keys at the edges (with some or other approach - there are a few)
yes, it exists, although s/keys is really deprecated in favor of schema/select in spec 2
but there is also the notion of closed spec checking which limits things somewhat (and plumbing to add other such options during checking)
> yes, it exists, although s/keys is really deprecated in favor of schema/select in spec 2
So it also exists when using select
in a vanilla fashion, right?
I think so? can't remember