Yes, I think most of the problems can be solved through prefixing (although
the solution is a bit hacky, IMO) but the real problem with the global
registry is that its not based on an abstraction but a concrete
implementation.  The only specific problem I can think of right now is the
incidental complexity related to garbage collection - like Steve points out.

If the registry were based on an abstraction, I can imagine a few fun
experiments.  Right now, the implementation assumes that the registry is
loaded when a namespace is initialized.  Why not load the registry from a
database, edn files or off the network?  Piling onto the network idea, why
not have a true global registry which gets updated as Clojure developers
publish specs in real time?

On Mon, Jun 12, 2017 at 4:47 PM Steve Buikhuizen <steve.buikhui...@gmail.com>
wrote:

> I can think of a use-case in support of Mark's position.
>
> If you are building a hosted ETL web service (like Mulesoft) and you want
> users to be able to use spec to validate records flowing through it.
>
> One customer wants :org/postcode to be integer (i.e. US) and another wants
> it to be string (i.e. UK) With a global registry this is not possible.
> It's possible to spec this but then you need to predict all the data
> shapes supported i.e. not an open validation system
>
> You can prefix the key with an org id e.g. :<id>.org/postcode but if you
> are hosting a lot of orgs the registry will become large.
>
> Removal could help manage space but it would require some kind of registry
> garbage collection i.e. incidental complexity.
>
> Any thoughts on how best to do this with spec? Could a multi-spec help
> here?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/4jhSCZaFQFY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to