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.
