This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-07
Channels
- # beginners (166)
- # cider (6)
- # cljs-dev (12)
- # cljsrn (64)
- # clojure (71)
- # clojure-chicago (1)
- # clojure-spec (14)
- # clojure-uk (2)
- # clojurescript (25)
- # datomic (2)
- # docs (1)
- # duct (1)
- # emacs (4)
- # fulcro (5)
- # graphql (3)
- # java (46)
- # mount (5)
- # off-topic (29)
- # onyx (1)
- # portkey (10)
- # re-frame (12)
- # remote-jobs (1)
- # shadow-cljs (46)
- # spacemacs (1)
- # specter (4)
- # vim (2)
@kardan it has become commonplace to use unsegmented namespaces for domain specific entities like :user/email
But I'd also love if someone wrote a state of the art summary because there is still lots of experimentation going on
@kardan consider that in your example you usually don't come up with a single user spec
in practice you end up creating different specs with keys in the usernamespace depending on what you need
for example an api that changes a user may say all user keys are optional
an api that creates a user may have some required user namespaced keys
this flexibility is easily missed when you are looking to create "the" ::user spec
the great thing is that you can compose and mix the keys freely in the context you need them whereas in classical type systems you need inheritance or whatever to reuse them.
unsegmented namespaces are not safe, :user/id
might mean different things in different domains. If you need to integrate the two domains, you'll have conflictings specs.
@ikitommi It all depends on the scope of the data. If you're writing an application, not a library, and you have data whose scope is just that application, and that data is used entirely internally in that application, then something like :user/email
might be fine. If that needs to flow through other code for additional processing, then you might want a more unique prefix. If data is truly isolated to a single namespace for processing (and is entirely opaque to everything else), the ::email
would make more sense. If the data does lie somewhere in between, a "reasonably" unique prefix should be sufficient. Using namespace aliases makes working with namespaced maps a lot less painful -- and you can decide whether those should be real (code-based) namespaces or just arbitrary namespace prefixes independent of the alias. /cc @kardan
I'm starting a wrapper for an interesting Java library, for which I have domain knowledge of the problem they're working on. I am interested in adding specs based on invariants that I know so as to make it easier to use this library. Advice on how to approach such a goal is most welcome.
Perhaps this post would be helpful? http://blog.cognitect.com/blog/2017/6/19/improving-on-types-specing-a-java-library
@U08EKSQMS This is exactly the kind of thing I was looking for, thank you!