I'm learning Clojure via a pet project. The project would consist of several workers that would be called from other functions.
Each worker is defined in their own namespace as a set of functions (currently two: get-data for gathering data and write-data for writing the gathered data into a file).
In order to make the code a bit DRYer, I decided to write a macro that would gather functions from namespace into a map that can be passed around:
(ns clojure-bgproc.workers)
(defmacro gen-worker-info []
(let [get-data (ns-resolve *ns* 'get-data)
write-data (ns-resolve *ns* 'write-data)]
`(def ~(quote worker-info)
{:get-data ~get-data
:write-data ~write-data}
)
)
)
In my worker code, I use my macro (code abridged for clarity):
(ns clojure-bgproc.workers.summary
(:require [clojure-bgproc.workers :refer [gen-worker-info]]))
(defn get-data [params]
<...>
)
(defn write-data [data file]
;; <...>
)
(gen-worker-info)
While it does work (I get my get-data and write-data functions in clojure-bgproc.workers.summary/worker-info, I find it a bit icky, especially since, if I move the macro call to the top of the file, it doesn't work.
My question is, is there a more idiomatic way to do so? Is this idiomatic Clojure at all?
Thank you.
I think you're in a weird spot because you've structured your program wrong:
Each worker is defined in their own namespace as a set of functions
This is the real problem. Namespaces are a good place to put functions and values that you will refer to in hand-written code. For stuff you want to access programmatically, they are not a good storage space. Instead, make the data you want to access first-class by putting it into an ordinary proper data structure, and then it's easy to manipulate.
For example, this worker-info map you're thinking of deriving from the namespace is great! In fact, that should be the only way workers are represented: as a map with keys for the worker's functions. Then you just define somewhere a list (or vector, or map) of such worker maps, and that's your list of workers. No messing about with namespaces needed.
My go-to solution for defining the workers would be Protocols. I would also apply some of the well-tried frameworks for system lifecycle management.
Protocols provide a way of defining a set of methods and their signatures. You may think of them as similar, but more flexible than, interfaces in object-oriented programming.
Your workers will probably have some state and life-cycle, e.g., the workers may be running or stopped, acquiring and releasing a resource, and so on. I suggest you take a look at Integrant for managing a system with stateful components (i.e., workers).
I would argue for avoiding macros in this case. The adage data over functions over macros seems to apply here. Macros are not available at runtime, make debugging harder, and force all other programmers who look at your code to learn a new Domain-Specific Language, i.e., the one you defined with your macros.
Related
I am new to Clojure, so perhaps this is a really obvious question, but I cannot find any useful answer.
I am implementing a REST service with Spring Boot which uses Clojure to calculate the result by means of multiple calls to Compiler.eval(). I have some Clojure stuff that is supposed to be shared among all requests (constants, functions, global variables, etc.), and well as some per-request stuff that should be isolated and unique for each request.
I run this service as executable JAR with clojure.jar in the classpath. However, from JVM's perspective, you can only access Clojure through static methods, which means there is only one "instance of Clojure" per JVM. This means that if you eval (def a 1) during one request, "a" becomes visible to other requests as well.
Question 1: where and how should I define dynamic (request-scoped) variables/symbols in Clojure?
Question 2: Suppose I want a completely "new" Clojure instance for every request. How could I achieve that? So for example, I could have the variable with the same name and in the same namespace, but with different values, in the same JVM? I know I can load a whole new set of Clojure classes by using a fresh classloader, but that seems horribly cumbersome.
You shouldn't use global variables in Clojure, unless it is needed to keep track of some global "state", which has to be shared among all functions. It's a functional language (well, mostly) and the functional way of doing things is passing all required stuff along as arguments. That's how you get referential transparency and how you avoid functions seeing and influcencing each-other's values.
I don't know why you want to use SpringBoot for this, but maybe you could take a look at how Clojure-native web libraries work. They usually pass along some kind of "request context" to the handlers, where all necessary information is stored.
For instance Yada or Ring.
So to answer your (1): pass them in with each request.
And (2): you don't need that if you pass in new values per request.
Although using globals that are local to one request (pardon the ugly expression) is not a generally recommended way to do web services in Clojure, let's say you have a valid use case for this. One such use case could be building an online REPL like tryclj.com.
A possibility to isolate requests would then be to create a temporary (random) namespace for each request, and wipe the namespace after each request. tryclojure does this for requests using clojail for sandboxing (snippet from src/tryclojure/models/eval.clj):
(defn make-sandbox []
(sandbox try-clojure-tester
:timeout 2000
:init '(do (require '[clojure.repl :refer [doc source]])
(future (Thread/sleep 600000)
(-> *ns* .getName remove-ns)))))
I'm trying to advise a number of methods in one library with utility functions from another library, where some of the methods to be advised are defined with (defn) and some are defined with (defprotocol).
Right now I'm using this library, which uses (alter-var-root). I don't care which library I use (or whether I hand-roll my own).
The problem I'm running into right now is that protocol methods sometimes can be advised, and sometimes cannot, depending on factors that are not perfectly clear to me.
If I define a protocol, then define a type and implement that protocol in-line, then advising never seems to work. I am assuming this is because the type extends the JVM interface directly and skips the vars.
If, in a single namespace, I define a protocol, then advise its methods, and then extend the protocol to a type, the advising will not work.
If, in a single namespace, I define a protocol, then extend the protocol to a type, then advise the protocol's methods, the advising will work.
What I would like to do is find a method of advising that works reliably and does not rely on undefined implementation details. Is this possible?
Clojure itself doesn't provide any possibilities to advice functions in a reliable way, even those defined via def/defn. Consider the following example:
(require '[richelieu.core :as advice])
(advice/defadvice add-one [f x] (inc (f x)))
(defn func-1 [x] x)
(def func-2 func-1)
(advice/advise-var #'func-1 add-one)
> (func-1 0)
1
> (func-2 0)
0
After evaluation of the form (def func-2 func-1), var func-2 will contain binding of var func-1 (in other words its value), so advice-var won't affect it.
Eventhough, definitions like func-2 are rare, you may have noticed or used the following:
(defn generic-function [generic-parameter x y z]
...)
(def specific-function-1 (partial generic-function <specific-arg-1>))
(def specific-function-2 (partial generic-function <specific-arg-2>))
...
If you advice generic-function, none of specific functions will work as expected due to peculiarity described above.
If advising is critical for you, as a solution that may work, I'd suppose the following: since Clojure functions are compiled to java classes, you may try to replace java method invoke with other method that had desired behaviour (however, things become more complicated when talking about replacing protocol/interface methods: seems that you'll have to replace needed method in every class that implements particular protocol/interface).
Otherwise, you'll need explicit wrapper for every function that you want to advice. Macros may help to reduce boilerplate in this case.
Given that each Clojure namespace corresponds to a file, isn't it the case that a public function, macro, etc. can never be moved out of that file without breaking backward compatibility?
This seems like a surprisingly rigid system--essentially, refactoring of public-facing code can only be done within a single file.
Is there a technical reason for this limitation? Something to do with Java interop, maybe?
You can split a single namespace into multiple files ( see Splitting a Clojure namespace over multiple files ) but it is quite rare to do so. Also you can import-vars using https://github.com/ztellman/potemkin but again this is rarely done in practice. Clojure libraries tend to have relatively small public interfaces, perhaps because they usually operate on common data structures. As such there are rarely files with much code in them.
If you are wanting to preserve backwards compatibility, you can def a var into a namespace (or even within a namespace with a different name), to ensure that any callers will still resolve to the right function.
Functions that are not considered part of the public api can be marked private, which leaves the opportunity for later refactoring without breaking calling code. Any changes to a public api will, of course, risk breaking backwards compatibility and there will a trade off between that breaking change and introducing a new api with redundant functionality.
(ns foo)
;; only visible in the foo ns
(defn- a-private-fn [] ...)
;; only visible in the foo ns
(def ^:private a-private-var BAR 1)
I spent a couple of years doing Scheme "back in the day" and am now learning Clojure. One of the "best practices" in Scheme was to define helper functions within the parent function thus limiting their visibility from "outside." Of course back then TDD wasn't done (or known!) so testing such functions wasn't an issue.
I'm still tempted to structure Clojure functions this way; i.e., using letfn to bind helper functions within the main function. Of course testing such "local" functions is problematic. I realize I can define "private" functions, but this scopes the visibility to the namespace which helps, but is not as fine grained. If you come upon a letfn within another function it's pretty clear that the function is not available for general use.
So, my question is, can one test such local functions and if so, how? If not, then is there some convention to aid in code reading so that it's clear that a function has only one caller?
TIA,
Bill
The usual approach is to just put the functions in the namespace.
One option is using metadata:
user=> (defn ^{::square #(* % %)} cube [x]
#_=> (* x ((::square (meta #'cube)) x)))
#'user/cube
user=> (meta #'cube)
{…, :user/square #<user$fn__780 user$fn__780#2e62c3f9>}
user=> (cube 3)
27
It is of course possible to write a macro to make this prettier.
I'm using Datomic in several projects and it's time to move all the common code to a small utilities library.
One challenge is to deal with a shared database uri, on which most operations depend, but must be set by the project using the library. I wonder if there is a well-established way to do this. Here are some alternatives I've thought about:
Dropping the uri symbol in the library and adding the uri as an argument to every function that accesses the database
Altering it via alter-var-root, or similar mechanism, in an init function
Keeping it in the library as a dynamic var *uri* and overriding the value in a hopefully small adapter layer like
(def my-url ...bla...)
(defn my-fun [args]
(with-datomic-uri my-uri
(apply library/my-fun args))
Keeping uri as an atom in the library
There was a presentation from Stuart Sierra last Clojure/West, called Clojure in the Large, dealing with design patterns for larger Clojure applications.
One of those was the problem you describe.
To summarize tips regarding the problem at hand:
1 Clear constructor
So you have a well defined initial state.
(defn make-connection [uri]
{:uri uri
...}
2 Make dependencies clear
(defn update-db [connection]
...
3 It's easier to test
(deftest t-update
(let [conn (make-connection)]
(is (= ... (update-db conn)))))
4 Safer to reload
(require ... :reload)
Keeping uri in a variable to be bound later is pretty common, but introduces hidden dependencies, also assumes body starts and ends on a single thread.
Watch the talk, many more tips on design.
My feeling is to keep most datomic code as free of implicit state as possible.
Have query functions take a database value. Have write functions (transact) take a database connection. That maximizes potential reuse and avoids implicit assumptions like only ever talking to one database connection or inadvertently implicitly hardcoding query functions to only work on the current database value - as opposed to past (as-of) or "future" (with) database values.
Coordinating a single common connection for the standard use case of the library then becomes the job of small additional namespace. Using an atom makes sense here to hold the uri or connection. A few convenience macros, perhaps called with-connection, and with-current-db could then wrap the main library functions if manually coding for and passing connection and database values is a nuisance.