Fork me on GitHub

@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.


@U08EKSQMS This is exactly the kind of thing I was looking for, thank you!


np, good luck!