Who Uses import-vars?

[Nick Mudge]

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?

[Duncan McGreggor]

I use it in some large fraction of my Clojure projects (25-50%?). The primary driver is to balance an "internal" organization (e.g., that allows me to keep file line counts low) that would be cumbersome as an API vs. an ideal "developer experience" (e.g., less hierarchy and easier access to functions).

I've also used it more recently in a large, legacy project (7+ years) to support old users of a non-versioned API while reorganizing the codebase to be more consistent (i.e., harmonizing a half-decade's worth of changes). potemkin made the end result very clean with no breaking changes and really opened up the future for the project.

d

--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Timothy Baldridge]

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

--
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+unsubscribe@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+unsubscribe@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)

[Duncan McGreggor]

On 7 November 2017 at 13:11, Timothy Baldridge <tbald...@gmail.com> 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

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.*. 

This is a great practice; it's how I do all my protocols/implementations now.

 

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. 

Huh. Good to know. Will have to ponder ...

d

[Nick Mudge]

Thanks Ducan, this is incredibly useful!

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.

[Nick Mudge]

Thanks Timothy, this is really useful!

On Tuesday, November 7, 2017 at 11:11:30 AM UTC-8, 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

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.

[Alan Thompson]

In the Tupelo library, I have been using `import-fn` and `import-macro` from Potemkin so that I can define functions/macros in a single namespace `tupelo.impl`, but then expose an API in "user-visible" namespaces like:

• tupelo.core
• tupelo.char
• tupelo.test
• etc

Perhaps I've been doing it wrong and should switch to `import-vars`.....?

Alan

--
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+unsubscribe@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+unsubscribe@googlegroups.com.

[Nick Mudge]

I think import-vars is for convenience. It delegates to import-fn and import-macro. 

On Tuesday, November 7, 2017 at 12:09:10 PM UTC-8, Alan Thompson wrote:

In the Tupelo library, I have been using `import-fn` and `import-macro` from Potemkin so that I can define functions/macros in a single namespace `tupelo.impl`, but then expose an API in "user-visible" namespaces like:

• tupelo.core
• tupelo.char
• tupelo.test
• etc

Perhaps I've been doing it wrong and should switch to `import-vars`.....?

Alan

On Tue, Nov 7, 2017 at 10: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.

[Alan Thompson]

Looking at the source code here I can see that `import-vars` delegates to `import-fn` or `import-macro`, which in turn calls `link-vars`. That uses `add-watch` with a function described by the docstring:  "Makes sure that all changes to `src` are reflected in `dst`."

​I haven't seen any problems in using it for a year or so, but the implementation is not the same as I expected.  Hmmm.

Alan​

[Alex Miller]

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.

[Sean Corfield]

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?

 

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.

[Didier]

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.

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)

[platon...@gmail.com]

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. I think Zach would be happy to include any and all real issues in the Potemkin's docs. 

[Didier]

So is there another way then using import-vars tp break up an existing package into many new small ones?