9

I may very well be approaching this in the wrong way, so please forgive me of my naiveté:

In order to learn Clojure I've begun porting my OAuth client library for Python to Clojure. I'm doing this by wrapping clj-http much in the same way I wrap Python Requests in the Python library. This seems to be working pretty well so far and I'm really enjoying seeing the implementation come to life in Clojure.

However I have run into a problem: I'm planning to support both OAuth 1.0 and 2.0 and have split the respective functions into two files: oauth1.clj and oauth2.clj. Now, each file should ideally expose a set of functions which correspond to HTTP verbs.

(ns accord.oauth2)

...

(defn get
  [serv uri & [req]]
  ((:request serv) serv (merge req {:method :get :url uri})))

These functions will be essentially identical and in fact right now are completely identical between oauth1.clj and oauth2.clj. My first reaction was to move these functions into core.clj and then require them in the respective OAuth namespaces (oauth1, oauth2) so as to avoid writing the same code twice.

This is fine so long as I use the referred functions in the file, i.e. oauth1.clj or oauth2.clj. But let's say we want to use this library as I'm intending (here in the REPL, alternatively your program), something like this:

=> (require '[accord.oauth2 :as oauth2])  ;; require the library's oauth2 namespace

...

=> (oauth2/get my-service "http://example.com/endpoint")  ;; use the HTTP functions

The var oauth2/get is not found because pulling it into the namespace in oauth2.clj alone doesn't seem to expose it as though it were actually in that namespace. I don't want to wrap them with more functions, because that basically defeats the purpose; the functions are so simple (they just wrap a request function) I would be writing them in three places, essentially, if I were to do that.

I'm sure I'm not grokking namespaces in Clojure properly and moreover maybe the general way of thinking about abstraction problems and code sharing idiomatically.

So I'm wondering what the idiomatic solution to this is? Am I going about this completely the wrong way?

Edit:

Here's a simplification of the problem: https://gist.github.com/maxcountryman/5228259

Note that the the goal is to write the HTTP verb functions one time. They don't need special dispatch types or something like that. They're already fine as they are. The issue is that they aren't exposed from accord.oauth1 or accord.oauth2, i.e. when your program requires accord.oauth2 for instance.

If this were Python we could just import the functions like this: from accord.core import get, post, put, ... into accord.oauth1 and accord.oauth2 and then when we used the accord.oauth1 module we would have access to all those imported functions, e.g. import accord.oauth2 as oauth2 ... oauth2.get(...).

How can we do this in Clojure or how should we idiomatically provide for this kind of DRY abstraction?

Improve this question
14
  • "My first reaction was to move these functions into core.clj and then require them in the respective OAuth namespaces (oauth1, oauth2) so as to avoid writing the same code twice." Did you do this? If you did, why do you need to require it in the second code block? What file/namespace is this second code block in? Commented Mar 23, 2013 at 0:36
  • Please provide the specific compiler error. Commented Mar 23, 2013 at 0:39
  • @tieTYT I moved the HTTP verb-related functions into core.clj which is the accord.core namespace. Then the accord.oauth1 and accord.oauth2 namespaces require these functions by referring :all from accord.core into their respective namespaces. The problem with this is you can't then require accord.oauth2, say in the REPL or from your program, and then use the HTTP functions in this way: accord.oauth2/get. If the functions were actually written, twice, in each file, that would work. I'm trying to avoid that, however. :) Commented Mar 23, 2013 at 0:42
  • 2
    I have two ideas. 1) Refactor your code to have a third namespace, something like accord.oauth-common, and import that to get the common functions, or 2) just use def to re-bind the functions you want in each namespace (rather than fully re-declaring them), e.g. (def get oauth1/get). I'd personally go with the first option. Commented Mar 23, 2013 at 6:24
  • 1
    @maxcountryman - In the context of your gist, what I was suggesting is that you should just (ns testing.bar (:use [test core baz])) in bar.clj. Commented Mar 23, 2013 at 17:33

3 Answers 3

Reset to default
5

Consider having a look at Zach Tellman's library Potemkin. Zach describes it as "a collection of functions for reorganizing the structure of namespaces and code".

Potemkin isn't without controversy. Here's the start of a thread on the Clojure mailing list where Stuart Sierra is clear that he's not a fan of the idea.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks, this thread you linked is quite informative. It seems the general consensus is you can't (rather, shouldn't) emulate the Python way. Instead you should keep namespaces flat. So I'm thinking the best thing for me to do here is just have the user require two namespaces: accord.oauth2 and accord.core, which could work like this: (require '[accord.oauth2 :as oauth2]) and (require '[accord.core :as client]) then (def serv (oauth2/service ...)) and (client/get serv ...).
2

I'm going to answer my question although thank you to everyone who commented: Andrew's answer is very informative and while it doesn't quite answer the question it certainly does lead to answers. I do think Potemkin will do this but I went ahead and wrote my own solution based on this thread. I will say I don't feel this approach is generally idiomatic, based on some responses here and further discussion in IRC, however it may make sense for limited use cases, such as mine.

But to answer the question, this function should do what I had originally intended:

(defn immigrate
  [from-ns]
  (require from-ns)
  (doseq [[sym v] (ns-publics (find-ns from-ns))]
    (let [target (if (bound? v)
                  (intern *ns* sym (var-get v))
                  (intern *ns* sym))]
      (->>
        (select-keys (meta target) [:name :ns])
        (merge (meta v))
        (with-meta '~target)))))

Then you could invoke it something like this, let's say we put this in foo.clj (if you see the gist I added in the edit):

(ns testing.foo)

(immigrate `testing.baz)

Now if we require testing.foo in the REPL:

=> (require '[testing.foo :as foo])
=> (foo/qux "hi!")
;; "hi!"

After speaking with Stuart Sierra on IRC and reading the email thread Andrew linked, I came to the conclusion that this is not necessarily the intended way to use namespaces.

Instead a better way to implement my library might look like this:

=> (require '[accord.oauth2 :as oauth2])
=> (def my-serv (oauth2/service 123 456 ...))
=> (require '[accord.http :as http])
=> (http/get my-serv "http://example.com/endpoint")

However given that I want to present the end-user with the cleanest API as possible, I may go ahead and use the immigrate function in this very limited scope of "importing" the HTTP method functions.

Edit:

After further discussion, I think the above solution should not generally be used, as I said already. And for my use-case I'll probably go with my last solution, i.e. using two separate namespaces.

Improve this answer

Comments

0

One option to design the solution would be to use multimethods with default implementation provided.

;The multi methods which dispatch on type param
(defmulti get (fn [serv uri & [req]] serv))
(defmulti post (fn [serv uri & [req]] serv))

;get default implementation for any type if the type doesn't provide its own implementation
(defmethod get :default [serv uri & [req]]
  "This is general get")

;post doesn't have default implementation and provided specific implementation.
(defmethod post :oauth1 [serv uri & [req]]
  "This is post for oauth1")

(defmethod post :oauth2 [serv uri & [req]]
  "This is post for oauth2")


;Usage
(get :oauth1 uri req) ;will call the default implementation
(get :oauth2 uri req) ;will call the default implementation
(post :oauth1 uri req) ;specific implementation call
(post :oauth2 uri req) ;specific call
Improve this answer

1 Comment

The serv parameter will differentiate the functions. There's no need to write them twice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.