Are functions dispatched by defmulti executing in the context/scope of the dispatcher?
I want to set a dynamic var *foo* for dispatched defmethod call.
I have a feeling that I will need to wrap the call to the dispatcher but wanted to confirm with the Clojure magicians.
RESOLVED
As per underlying suspicions confirmed by #schaueho, the following does what I need
;; Multimethod dispatch
(defmulti consume :type)
;; wrapper for dispatch
(defn consume-it [{:keys [token-fn]:as expression}]
"Wraps consume to imbue term name resolutions"
(if token-fn
(binding [*lookup-fn* token-fn]
(consume expression))
(consume expression)))
If I understand you correctly, you would like to use binding within the dispatch function. The purpose of the dispatch function is to return a value that will be used to identify the method to invoke, not to actually call the identified method.
(def ^:dynamic *dynvar* nil)
(defmulti mymulti
(fn [two args]
(binding [*dynvar* (new-value two args)]
(compute-dispatch-value two args)))
In this example, compute-dispatch-value would be see the new binding of *dynvar*, but any invoked method afterwards wouldn't.
Related
I have one function that does some (possibly lengthy) work (defn workwork [x] ...) and some other functions to check if the call will succeed ahead of time (defn workwork-precondition-1 [x] ...).
The precondition functions should be evaluated every time workwork is called (e.g. using :pre). The precondition functions should also be collected (and:ed) in a single function and made available to client code directly (e.g. to disable a button).
Which is the idiomatic way to solve this in Clojure while avoiding code duplication?
In particular, is there any way to evaluate the pre-conditions of a function without running the function body?
You can just collect your preconditions into a function:
(defn foo-pre [x]
(even? x))
Then call the function in a :pre-style precondition:
(defn foo [x]
{:pre [(foo-pre x)]}
…)
For functions introduced using defn, you can extract the :pre-style preconditions from the metadata on the Var:
(-> #'foo meta :arglists first meta)
;= {:pre [(foo-pre x)]}
And similarly for the :arglists entries for any other arities.
There are two caveats here:
The automatically-generated :arglists entry in the Var's metadata maybe be overridden. Overriding :arglists results in the above kind of useful automatically-generated metadata to be thrown out.
The {:pre [(foo-pre x)]} value returned by the above (-> #'foo meta …) expression contains foo-pre as a literal symbol – it'd be your responsibility to figure out which function it referred to at foo's point of definition. (This may or may not be possible – for example foo could be defn'd inside a top-level let or letfn form, with foo-pre a local function.)
And finally, anonymous functions may use :pre and :post, but there is currently no mechanism for extracting them from the function itself.
to evaluate the function precondition without running the function body,you can use robert-hooke library https://github.com/technomancy/robert-hooke/
(use 'robert.hooke)
(defn workwork [x] ...)
(defn workwork-precondition-1
[f x]
(if (precondition-1-satisfied? x)
(f x)
:precondition-1-not-satisfied))
(add-hook #'workwork #'workwork-precondition-1)
I have a method on an object.
myObject.myMethod(1)
I can invoke this in Clojure
(.myMethod myObject 1)
I can also invoke it using information from the lexical environment
(let [x 1] (.myMethod myObject x))
Can I do this with a partial? E.g.
(let [myPartial (partial .myMethod myObject)]
(myPartial 1))
This gives me a
java.lang.RuntimeException: Unable to resolve symbol: .myMethod in this context
I'm currently making this work with an anonymous function
(let [myThing #(.myMethod myObject %)]
(myThing 1))
But if it would be nice to use a partial in this case. Is it possible?
I'm sure the answer will be to do with binding and dispatch but I don't yet have a feeling for where during the compiling and execution the dispatch happens.
You can have partial in your case, use (memfn).
(memfn myMethod args)
In the REPL:
user=> (doc memfn)
-------------------------
clojure.core/memfn
([name & args])
Macro
Expands into code that creates a fn that expects to be passed an
object and any args and calls the named instance method on the
object passing the args. Use when you want to treat a Java method as
a first-class fn. name may be type-hinted with the method receiver's
type in order to avoid reflective calls.
I wish to know what is the idiomatic way to achieve data encapsulation
in Clojure. Below I describe my particular use case to motivate the example
code I provide.
I have code in a dbaccess module that performs a complex
database query to fetch some
data from a database. I also have a number of functions that operate
on the returned, raw, data. These functions then provide more
processed, refined views of the data and are invoked numerous
times with different arguments from
other modules in the system. Let's call them "API functions".
The query is heavy and should execute only once at the beginning,
the API functions will then operate on the raw-data
from memory without having to perform another DB query.
Here's my approach using closures:
dbaccess module
(ns dbaccess)
(let
[raw-data (complex-database-query)]
(defn create-client-names []
(fn [some-args] raw-data))
(defn create-client-portfolio []
(fn [some-args] raw-data))
(defn create-client-stocks []
(fn [some-args] raw-data)))
some other client module
(def client-names (create-client-names))
(doall (map println (client-names "Baltimore")))
I dislike having to name the created functions that have
captured the raw-data.
More importantly, the code above doesn't allow
the client modules to configure aspects of the query before it executes
(e.g. the database connection information).
If, on the other hand, closures are not used I will have to
explicitly pass the raw-data
back and forth between the dbaccess module and the other modules that need to invoke API functions.
Is there a better way? Should I perhaps use mutable state in the dbaccess module?
I will have to explicitly pass the raw-data back and forth between the
dbaccess module and the other modules that need to invoke API
functions
You should do this, pass the data the function need explicitly, because:
This will lead to loose coupling between how the data is created and how it is processed.
Functions will be more clear to understand while reading it.
Testing of the individual function will be easy as you can mock data easily.
I guess you don't need let in this case:
(def ^:private raw-data (promise))
(future (deliver raw-date (complex-database-query))) ;; A. Webb mentioned this
(defn create-client-names []
(fn [some-args] #raw-data))
...
Why aren't create-client-names and other functions just
(defn create-client-names [some-args]
#raw-data)
...
?
And IMO It's better to use doseq instead of map if there is imperative body:
(doseq [name (client-names "Baltimore")]
(println name))
For the sake of example, suppose I've wrapped a StringBuilder in a function so I can use it more easily in Clojure. I can easily make the no-arg version of the function call toString on the buffer e.g.
(defn builder
([^StringBuilder sb]
(fn
([] (.toString sb))
([& args]
(doseq [arg args]
(.append sb arg)))))
([] (builder (StringBuilder.))))
This is perfectly workable, however, I wonder how I could just override .toString() on the function itself so I could return the state of the StringBuilder or any other object that I have closed over.
You could try using https://github.com/technomancy/serializable-fn, which makes functions include their closed-over scope when they print. It will print the pr-str of the stringbuilder, though, which may or may not be exactly what you want.
In Clojure, how to use a java Class that is stored in a variable?
How should I fix the following code?
(def a java.lang.String)
(new a "1"); CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: a
And why this one works fine?
(def a str)
(a "1")
The most elegant solution is to write construct that does the same as new but is able to receive a class dynamically:
(defn construct [klass & args]
(clojure.lang.Reflector/invokeConstructor klass (into-array Object args)))
(def a HashSet)
(construct a '(1 2 3)); It works!!!
This solution overcomes the limitation of #mikera's answer (see comments).
Special Thanks to #Michał Marczyk that made me aware of invokeConstructor answering another question of mine: Clojure: how to create a record inside a function?.
Another option is to store the call to the constructor as an anonymous function. In our case:
(def a #(String. %1))
(a "111"); "111"
When you define a in this way, you get a var containing a java.lang.Class
(def a java.lang.String)
(type a)
=> java.lang.Class
You then have 2 options:
A: Construct the new instance dynamically by finding the Java constructor using the reflection API. Note that as Yehonathan points out you need to use the exact class defined in the constructor signature (a subclass won't work as it won't find the correct signature):
(defn construct [klass & args]
(.newInstance
(.getConstructor klass (into-array java.lang.Class (map type args)))
(object-array args)))
(construct a "Foobar!")
=> "Foobar!"
B: Construct using Clojure's Java interop, which will require an eval:
(defn new-class [klass & args]
(eval `(new ~klass ~#args)))
(new-class a "Hello!")
=> "Hello!"
Note that method A is considerably faster (about 60x faster on my machine), I think mainly because it avoids the overhead of invoking the Clojure compiler for each eval statement.
The problem is that Clojure implements Java interop using a number of special forms:
user=> (doc new)
-------------------------
new
Special Form
Please see http://clojure.org/special_forms#new
nil
this basically means the "normal" Clojure syntax is altered to allow for handier constructs when calling Java. As a naive reflection solution to your dynamic Java needs, you can leverage eval:
user=> (def a String) ; java.lang package is implicitly imported
#'user/a
user=> `(new ~a "test") ; syntax quote to create the correct form
(new java.lang.String "test")
user=> (eval `(new ~a "test")) ; eval to execute
"test"
The same strategy works with all the other interop special forms, like method invocation.
EDIT: look also at the answer from #mikera for a more performing alternative via the Java reflection API.