This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-23
Channels
- # babashka (22)
- # beginners (8)
- # calva (7)
- # clj-kondo (65)
- # cljdoc (9)
- # cljsrn (1)
- # clojure (53)
- # clojure-australia (4)
- # clojure-europe (49)
- # clojure-gamedev (2)
- # clojure-italy (13)
- # clojure-nl (1)
- # clojure-spec (19)
- # clojure-uk (4)
- # clojurescript (48)
- # clojureverse-ops (1)
- # core-async (3)
- # css (2)
- # cursive (15)
- # datomic (6)
- # degree9 (2)
- # depstar (4)
- # emacs (2)
- # find-my-lib (1)
- # fulcro (16)
- # graalvm (11)
- # gratitude (1)
- # honeysql (9)
- # introduce-yourself (2)
- # jobs (1)
- # joker (2)
- # livestream (2)
- # malli (16)
- # nbb (4)
- # news-and-articles (2)
- # off-topic (1)
- # pathom (7)
- # polylith (10)
- # practicalli (1)
- # re-frame (7)
- # reitit (1)
- # releases (3)
- # remote-jobs (1)
- # rewrite-clj (19)
- # shadow-cljs (10)
- # tools-build (1)
- # tools-deps (9)
- # uncomplicate (1)
- # vim (3)
- # xtdb (44)
Given an fdef
, can I get its source code back? Like clojure.repl/source
does with vanilla def
s
(my guess is that nope, but maybe someone wrote a thing?)
Maybe create a macro that uses a central registry to keep track of the source of each fdef, as per its fully evaluated name.
Not cool enough with macros to write the example, but it’d be something like, swap!
ing into your central atom, where you keep a map of fdef-symbol -> unevaluated source, and then of course evaluating your fdef normally afterwards.
This is just an off-hand idea, hope it makes sense
I think a minimalistic macro is a step in the right direction, thanks! Hadn't thought of that much
In that case I wouldn't need an extra atom - I could simply let clojure.repl/source
do its work
e.g. (defmacro def-fdef ..)
+ (def-fdef the-defn the-spec)
The macro would create a predictable symbol, like the-defn-fdef-source
. Then I (source the-defn-fdef-source)
hm, yeah, I guess 🙂
Not for the faint of heart https://github.com/reducecombine/.lein/commit/ca5bccefd672191d5c703047d4e206304cac9453
Currently, on spec alpha 2, you can select things that are not in the schema passed. Is this expected behaviour?
(ns user
(:require [clojure.alpha.spec :as s]))
(s/def ::schema-field1 int?)
(s/def ::schema-field2 int?)
(s/def ::not-schema-field int?)
(s/def ::schema (s/schema [::field1 ::field2]))
(s/def ::selected (s/select ::schema [::schema-field1
::schema-field2
::not-schema-field]))
(s/valid? ::selected {::schema-field1 1
::schema-field2 2
::not-schema-field true}) => false
(s/valid? ::selected {::schema-field1 1
::schema-field2 2
::not-schema-field 3}) => true
schemas are not exclusive
Great, thank you! I think it’s great to contextually ‘extend’ schema selections to keywords not originally on the schema
Is there any reason to have a schema in select at all? This:
(s/select ::schema [::schema-field1
::schema-field2
::not-schema-field]))
and this:
(s/select [::schema-field1
::schema-field2
::not-schema-field]))
seem to express the sameclosed schema checking