I agree with Tim - I don't like any of the Potemkin import-* functionality. Every time I am working against libs like this, "go to source" ends up in the wrong place. From my perspective, this is a bit of complexity and redirection that serves little purpose other than to confuse those looking at the implementation. Using public/private vars and implementation namespaces is sufficient to cover every case I've found useful.
On Tuesday, November 7, 2017 at 1:11:30 PM UTC-6, tbc++ wrote: > > 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 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhalgari%2Fodin%2Fblob%2Fmaster%2Fsrc%2Fcom%2Ftbaldridge%2Fodin.clj&sa=D&sntz=1&usg=AFQjCNHH2bAyy2sk9v_ma_gNadeRoplzKg> > > 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". > > -- 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.
