On Monday, June 12, 2017 at 7:03:13 PM UTC-5, Mark wrote: > > 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. >
I look forward to when that is an issue. :) > 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? > Nothing is stopping you from running code to load the registry via a database, edn files, or off a network. s/form exists exactly for the purpose of allowing you to extract specs as edn suitable for sending through a network, files, etc. Also, saying no now does not mean saying no forever - we can always expand support for more registry support later. -- 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.
