I've used `import-vars` before, most notably in `java-time`. Even though I've never had any problems with the imported vars, I'm aware many people dislike the method so I'm writing the APIs in `$project.core` namespaces now.
Would be great if anyone who had problems or is otherwise directly aware of the drawbacks contributed to the issue in the Potemkin project <https://github.com/ztellman/potemkin/issues/50>. I think Zach would be happy to include any and all real issues in the Potemkin's docs. On Wednesday, November 8, 2017 at 3:25:30 AM UTC+1, Didier wrote: > > I found private/public works fine. I put my public interface at the bottom > of the file with a nice comment header. Using another namespace like .impl, > I've always had the issue that nobody on my team can agree with what the > name convention should be for what an impl namespace should be called š, > so private has had less controversy. It can lead to pretty large file, and > splitting namespaces across more then one file, even though supported, > messes up with a lot of tooling, so I also avoid that. > > I think, what I've struggled with is how to move an API to another > namespace, while maintaining backwards compatibility. This happens a lot > where I work, where we want to refactor the namespace structure, and move > things around, and rename namespaces, but we're not sure if there were > other packages that depend on it which would break. So I'd want to take the > existing namespace, and move all its vars in a new namespace, but where the > old namespace still exists as a frozen immutable interface that now maps > back to the new. Yet I've hesitated to use potemkin, because its non ideal. > I'm still hoping here for a better solution to this to show up. > > On Tuesday, 7 November 2017 13:42:16 UTC-8, Sean Corfield wrote: >> >> 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:* clo...@googlegroups.com <clo...@googlegroups.com> on behalf of >> Timothy Baldridge <tbald...@gmail.com> >> *Sent:* Tuesday, November 7, 2017 11:11:14 AM >> *To:* clo...@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 < >> ni...@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 clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@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.
