I’m with Timothy (and Alex) on Potemkin. For me, it’s been the source of some very weird transitive dependency bugs as well as strange binding issues across a number of projects where it has been dragged in by various third party libraries (e.g., clj-http). It’s made me very wary of it 😐
I have – very occasionally – used (home-grown) functionality to “import” vars from one namespace to another, but without the watchers or any other “magic”, and it’s been done only when the convenience of a loop to intern symbols dramatically outweighs the effort of writing the delegation functions by hand (expectations.clojure.test currently does that to expose much of the old expectations API as-is while I’m transitioning how the library works). I consider it very much an interim/transition solution, that should be avoided in normal production code. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ________________________________ From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Timothy Baldridge <tbaldri...@gmail.com> Sent: Tuesday, November 7, 2017 11:11:14 AM To: clojure@googlegroups.com Subject: Re: Who Uses import-vars? I structure my code very explicitly. Normally the most common constructs are put in a single file named after the library itself (not in core.clj, do that half your files will be named core). https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj Anything not in the API that should be unpublished to users is in other namespaces that are imported and wrapped by vars in the main namespace. This does several things: * Keeps the public interface in one place * Allows for a different public interface than the private one. Notice how Odin has its own version of `when`, pulling that off require a bit of careful macro usage, so I'd rather write that once under a different name, then rename it to `when`. * It's now simple to say "anything in this namespace is public and will not change" Core.async uses a pattern much like this, the API is in clojure.core.async, most of the logic is under *.async.impl.*. I don't recommend potemkin's import-vars at all. Clojure vars were not meant to exist in more than one namespace at a time, so potemkin pulls of its magic by linking two vars via watchers. This means that changes to one var can cause side-effects in the other. In addition, bindings don't convey properly (AFAIK), so if you using bindings on one var, the changes won't be seen in the other var. Remember: import-vars doesn't actually import anything, it simply creates a new var in the current namespace and links the two via a two-way binding. It's quite the hack, imo. So I have to agree with Potemkin's tagline on github: it's an idea that's "almost good". Timothy On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge <n...@perfectabstractions.com<mailto:n...@perfectabstractions.com>> wrote: I am interested to know if people/you use import-vars to decouple the structure of code from its API. import-vars is from the potemkin library: https://github.com/ztellman/potemkin If you don't use import-vars how do you structure your code and provide an API? -- 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<mailto: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<mailto:clojure%2bunsubscr...@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<mailto:clojure+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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<mailto: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.
