In general we tend to pass things like clients in as function arguments. So you may have (defn do-stuff [client ,,,] ,,,). This keeps your function pure and allows you to test it very easily.

Dependency injection libraries like https://github.com/stuartsierra/component, https://github.com/weavejester/integrant and https://github.com/weavejester/integrant can help you manage the starting/stopping and cross-referencing of stateful components like that.

But in some cases a bit of global state (with all its attendant problems) could be sufficient. For such cases I like https://github.com/metabase/toucan/blob/master/src/toucan/db.clj#L40-L48 kind of pattern.

If I understand your question correctly, the following code might help

user> (def get-client
        (let [myclient (atom nil)]
          (fn [] (if @myclient
                   (do (println "reusing") @myclient)
                   (do (println "creating") (reset! myclient 42) @myclient)))))
                     
#'user/get-client
user> (get-client)
creating
42
user> (get-client)
reusing
42
user> 

I.e. prefer a binding, and fall back to an atom.

Thanks both @UJY23QLS1 and @U0AT6MBUL for giving me a couple of options to think on here. I can see how I can apply these. I think I’ll ponder for a bit before I settle on an approach. One side-note, I realized I could “keep the function pure” by always passing the client along with the request, but I don’t want the users of the lib to have to deal with (or even know about) the client aspect of it.

I also see that these libraries you linked @UJY23QLS1, are aimed squarely at this situation. So I’m going to think about if I want / need to go that route of it it’s overkill for my fairly simple use case.

Yeah, it probably won't be worth it for simple cases.

Still, initializing some library state, passing it back to the caller, and expecting that state as a function argument, is quite a common pattern. E.g. https://github.com/seancorfield/next-jdbc#usage

Yeah, that I do realize. I’ve done that myself often over the years. I just dislike doing it in cases where there is no “other” reason for the caller to deal with the client - besides avoiding caching the client on the “backend”. It feel like I’m just dumping the problem onto the caller.

instead of seeing it as dumping the problem onto the caller, you can view it as giving the caller more explicit control over state management, which I think anyone consuming a Clojure library will appreciate.

Fair enough @UG00LE5TN, I’ll think on that.

Two common approaches are (foo client foo-args) and (foo foo-args {:client client :extra :opts}) - I think if the client state is something that is secondary to the problem and will unlikely be modified or need to considered by the API user, then perhaps the second approach is more appropriate (since the opts map is optional). Then the library could def or memoize a default client that is used if none is passed in. Two other approaches that I am not a fan of is multi-arity functions (with and without extra client arg); and dynamic vars. It's mostly a question of API aesthetics, but e.g. I would consider the first-arg approach for a database connection (a client API must know about and setup a DB conn) and the optional-map approach more for an overridable threadpool in an HTTP client libary. Also remember that it would be good if the convention is consistent for all functions in the library: they should all take the client as the first argument (e.g. a datasource in next.jdbc) or as the last argument in all variadic functions (e.g. the optional :registry key in all malli functions).

you can also ask in the #CG3AM2F7V channel. It looks like the problem might be that you're on a linux-amd64 and using a configuration for linux64.

Thanks a lot for the reply. I am going to reach out to the channel and convey to them my question.

"It looks like the problem might be that you're on a linux-amd64 and using a configuration for linux64." If this is really the cause of the error, do you have any idea on how am I going to fix this? Do I need to re-install something?

"It looks like the problem might be that you're on a linux-amd64 and using a configuration for linux64." What exactly do you mean by your reply? Does it have to do with my Java SDK installation?

it doesn't look like rocksdb has a native lib for linux-amd64

you can try using one of the other storage options, https://docs.xtdb.com/storage/

maybe jdbc?

Does this mean that I can use XTDB on linux if RocksDB is not going to work on it?

Ok, I will try jdbc. Thanks.

Thanks a lot. It now works!

For example, I am trying to wrap https://github.com/yogthos/migratus to make it a bit simpler to use. Its migrate and rollback functions take a config as a first argument. In my case, I currently have two environments: dev and prod, and I would like to default to dev. So, I wrapped them like so:

(defn- get-config
  ([]    (get-config ::postgres/dev))
  ([env] (update-in base-config [:db]
                    merge (env postgres/configs))))

(defn migrate
  ([]    (migrate ::postgres/dev))
  ([env] (-> env get-config migratus/migrate)))

(defn rollback
  ([]    (rollback ::postgres/dev))
  ([env] (-> env get-config migratus/rollback)))

Think of macros as functions around your code. Can you see where you could plug in parameters for each?

Although note that clojure generally discourages macros, as they add extra hidden complexity to code.

With that in mind, what would you like your macro api to look like? (wrap-migratus "dev")?

I was rather thinking about defining a macro to write 2-arity functions, such that I can write: (defoperation rollback migratus/rollback) Maybe that’s a bad idea, but that’s what instinctively comes to me when I see the above code. Maybe there are more idiomatic ways of dealing with the problem.

Sure, why not? That works well enough. Have you tried writing a macro yourself?

Well, I did but failed miserably. They are a bit tedious to write as well, the errors are not very clear for a beginner like me. With my current knowledge, it would take too much time to write it, and it would not be worth it in my opinion. That’s why I am inquiring about good examples in the wild, so that I can learn from good examples.

Oh right. Well I'm on the train home and it looked like fun, so

(ns scratch)

(defmacro defoperation
  [op-name op-reference]
  `(clojure.core/defn ~op-name
     ([]    (~op-name :ns.postgres/dev))
     ([env] (clojure.core/-> env get-config ~op-reference))))
(macroexpand-1
  '(defoperation rollback migratus/rollback))
;; => result
(clojure.core/defn
 rollback
 ([] (rollback :ns.postgres/dev))
 ([scratch/env]
  (clojure.core/-> scratch/env scratch/get-config migratus/rollback)))

Of note: it's probably a good idea to not rely on relative namespaces with macros

Actually that's probably a small error in there, one moment

I was going to ask the question. 😄

Updated

So things to note: because I didn't give env a namespace, it evals to the current namespace because of the backtick at the beginning

I specifically removed the :: from postgres/dev to something with an absolute namespace for the same sort of reason

Why macroexpand-1? I think I had a similar macro (delete it since :face_palm: ), but your macro also fails with macroexpand. It works with macroexpand-1.

So macroexpand will then expand every other macro below it

macroexpand-1 only does the top level macro

So you can do (-> form macroexpand-1 macroexpand-1) to do two macro expansions

That makes a lot of sense.

Thanks a lot for you time and clear explanations. 🙇

Note that I'm middling at best with macros. If you want to go heavy macros I'd recommend reading SICP

There's a lot of gotchas with macros and they're hard to reason about, so again it's generally recommended to avoid them in clojure without a very good reason

And probably not when it's only a couple of cases for your pattern. Probably more like when you have half a dozen items of very hairy syntax repeated the same way over and over

One good example (closed code but I can explain what it's doing) is importing a bunch of react components into reagent

So there's a bunch of slightly hairy stuff around looking up a name in a js list of objects, then defing each one with adapt-react-component

About 3-4 lines per entry. Not terrible but still painful when pulling in 30+ objects

So the declaration is instead something like (import-raws [Button Card Overlay ...])

And each item is now def'd in that namespace for import elsewhere

That makes sense. I agree that it’s overkill for my case, it felt like a good experiment though. Which is not over because the macro is not actually working 😄. macroexpand-1 is working, but macroexpand is not. It’s saying it does not conform to defn’s spec.

1. Caused by clojure.lang.ExceptionInfo
   Call to clojure.core/defn did not conform to spec.
   #:clojure.spec.alpha{:args
                        (migrate
                         ([] (migrate :me.postgres/dev))
                         ([me.migrations/env]
                          (clojure.core/->
                           me.migrations/env
                           me.migrations/get-config
                           migratus/migrate)))}

(`me` is the root namespace of my project)

Oh I see. me.migrations/env is throwing the error, can't be namespaced

(defmacro defoperation
  [op-name op-reference]
  `(clojure.core/defn ~op-name
     ([]    (~op-name :ns.postgres/dev))
     ([~'env] (clojure.core/-> ~'env get-config ~op-reference))))
;; =>
(clojure.core/defn
 rollback
 ([] (rollback :ns.postgres/dev))
 ([env] (clojure.core/-> env scratch/get-config migratus/rollback)))

So ~ is evaluate, so ~'env is evaluate (quote env), which makes it just the symbol env

(Well it's not quite evaluate, but it'll do for our understanding)

Now I understand the juggling with chainsaw analogy. 😄

Yeah.. as a learning exercise absolutely do some more, but avoid in codebases where possible

hahaha

Thanks for the solution and cautionary tale, it now works like a charm and will I avoid using it. 😄

Again, if you want to dive more into the wonderful world of macros (or just get an idea of what you can really do with them), have a read through SICP

Also so you can learn how to make hygienic macros

It feels like a threshold along the journey. Write macros because you think you need them, get bitten hard, stop using macros, carefully write macros. Like this meme with the gaussian curve.

I dunno, I'm pretty sure I'm not even at the peak of the curve, and I feel like after the peak there's the racketeers

And their brains are just the next level aliens I'm nowhere near yet

Like, this library https://docs.racket-lang.org/2d/

(I still like Clojure more than racket for sheer pragmatism and getting stuff done, but good god do they have some weird and cool stuff)

namespace :)

that will give you a string, which you can pass to symbol or keyword

that's what I get for trying to trust google instead of just looking back over https://clojure.github.io/clojure/clojure.core-api.html thanks!

You may also find one of the searchable cheastsheets here useful: https://jafingerhut.github.io/

Or in a REPL, the apropos and find-doc functions.

I hadn’t seen this cheatsheet, awesome

The official version on http://clojure.org has everything except the dynamic search text box, but you can use browser text search on the page to look for strings, too: https://clojure.org/api/cheatsheet. That page also has a link to the one that I gave above.

protocol methods are functions in the namespace where the protocol is defined, and you should treat them that way for calling purposes

ok makes sense from my poking at the repl

that means requiring the namespace defining the protocol and using function names that sufficiently refer to that (either by fully qualified name, aliased name, or by referring them to use as short name)

in fact that makes things simpler

excellent, thank you!

an important thing here is that functions are an abstraction and from the caller perspective, whether you are calling a function, a macro, a multimethod, a protocol method, a var that holds a map, etc - the caller says exactly the same thing (f args)

which means the implementor is free to change the implementation without affecting the caller

with that understanding I guess this should have been obvious

thanks again - this makes total sense

i'm not quite following. Do you have an example of how you want your function to behave? I was about to suggest looking into re-pattern, but I see that you've already found it.

here are some re-pattern examples: https://clojuredocs.org/clojure.core/re-pattern

(re-find (re-pattern "#.") "abc#def")
;; => "#d"

(re-find (re-pattern ".#.") "abc#def")
;; => "c#d"

The # prefix to regexes just tells the reader to call re-pattern on the following string

Your issue is likely the fact that you are prepending # onto the string of your regex to mimic the syntax of regex literals before passing to re-pattern

;; equivalent:
(re-find (re-pattern "#.") "abc#def")
(re-find #"#." "abc#def")

Hi all! Recently I have been a bit confused by how defmulti/defmethod works and I could not find anything to help me to understand what was going on or how to better approach my problem. What I wanted to do was to provide a pluggable interface to store and retrieve some data in a pet project, something that could be changed via simple configuration, which could look like this:

(def config {:persistence {:backend :json-file
                           :base-path "/some/path"}})

or

(def config {:persistence {:backend :jdbc
                           :connection-string "sqlite:///:memory:"}})

;; persistence.clj
(ns persistence)

(defmulti store-data! (fn [config id data] (:backend config)))

(defmulti get-data (fn [config id] (:backend config)))

;; persistence.json_file.clj
(ns persistence.json-file
  (:require [persistence :refer [store-data! get-data]]))

(defmethod store-data! :json-file
  [config id data]
  (store-data-to-filesystem (:base-path config) id data))

(defmethod get-data :json-file
  [config id]
  (get-data-from-sowmhere (:base-path config) id))

;; client-code.clj
(ns client
  (:require [persistence :refer [store-data! get-data]]))

;; ...and some code dealing with data...

FWIW, I do it the same way.

Yes, it works, but somehow I feel it is breaking the abstraction

Yeah, requiring an ns for no other reason than to get the methods defined feels odd, but it makes sense at least: how else is your Clojure to know that they exist? There are other, more dynamic ways to accomplish this (e.g. search for and loading code in the classpath), but they are a lot more involved.

the code using the abstraction does not have to be the same code that's configuring the extensions by loading them

but yes, someone has to load them

Thanks! Can someone point me to some docs/articles to help me understand how to achieve the dynamic loading you are mentioning?

I was just reading about this yesterday, but cannot remember where. Basically, if you do not require the namespace, then the JVM will not even bother building the class files. So you're doing it right by just requiring the namespace, even if it "feels weird".