[CLJ-1965] First-class metadata support for registered specs

104 views
Skip to first unread message

Josh Brandoff

unread,
Apr 4, 2017, 1:53:11 PM4/4/17
to Clojure Dev
Hi All!

Was looking at http://dev.clojure.org/jira/browse/CLJ-1965 and thinking of contributing. Does anyone know if there is any existing discussion or thoughts around this issue? Considering contributing code for it but would love to get some feedback from the community first (particularly since it would be my first contribution!).

Alex Miller

unread,
Apr 4, 2017, 1:58:05 PM4/4/17
to Clojure Dev
Hi Josh,

We have not yet discussed a recommended approach for this so are not currently looking for patches on it.

Alex

Linus Ericsson

unread,
Apr 4, 2017, 5:33:23 PM4/4/17
to cloju...@googlegroups.com
I felt a need to be able to generate spec and Datomic schemas in the same place while prototyping our application (which I'd say is "always", btw, which will have implications later on).

I made this possible by creating a parallell spec registry (simply map of keys, similar to the spec registry) and a special def-macro, called "schdef", which put the spec into the ordinary spec registry with s/def, and into the parallell registry with just a swap!. It works decently well for our use-case. Clojure.spec is a little limited in which things can be hooked into it, and I think part of it is to avoid this kind of overloading for now. 

We generate all our datomic schema from this during development, and it makes it a breeze to add new schema attributes and create initialized test dbs by reading the registry.

Of course there are downsides, but not in the double registry-atoms (at least not right now). One thing to explore more is the possibility to add warnings when one spec/schema-attribute update is incompatible with an attribute already in the registry, since this means our registry is most likely not coherent and could break based on load order (this happens most often when we put specs in shared libraries, and/or in test-namespaces, and can be tedious to track down - a more strict s/def mode could maybe be of help here - mostly for developer ergonomics). Maybe this could be solved with an emacs-mode or similar - like "highlight s/defs which are incompatible (whatever that may means) with the current spec on that key".

/Linus




--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscribe@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

Josh Brandoff

unread,
Apr 5, 2017, 9:07:08 AM4/5/17
to Clojure Dev
Thanks for sharing! We may take a similar approach for now :)
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages