CODEWITHSUNDEEP
clojure
deadghost
deadghost

Reputation: 5237

Group multiple namespace definitions under one namespace

Suppose I have the namespaces foo.car.components.engine, foo.car.components.transmission, foo.car.components.brakes.

In foo.car.components.engine there is (defn engine [] ...), foo.car.components.transmission there is (defn transmission [] ...), foo.car.components.brakes there is (defn brakes [] ...).

I'd like to make these available in foo.car.components such that other namespaces only need to require foo.car.components to use engine, transmission, and brakes.

The following works, but I'm wondering if there are cleaner ways to do this or if it's even good practice.

(ns foo.car.components
  (:require
   [foo.car.components.engine :as engine]
   [foo.car.components.transmission :as transmission]
   [foo.car.components.brakes :as brakes]))

(def engine engine/engine)
(def transmission transmission/transmission)
(def brakes brakes/brakes)

Upvotes: 1

Views: 169

Answers (4)

cjg
cjg

Reputation: 2684

I think the way you're doing it is the best way, because it makes explicit the sources of the defs in each namespace. If you have large namespaces with a lot of functions, you could write a basic helper function to do this for you:

(ns foo.utils)
(defn export-refs
  [target-ns source-namespaces]
  (doseq [ns source-namespaces
          [sym f] (ns-interns ns)
          :let [existing (get (ns-interns target-ns) sym)]]
    (when (and existing (not= (var-get existing) f))
      (throw (Exception.
               (format (str "Cannot refer to symbol %s in %s from %s, because that symbol "
                            "already exists in the target namespace")
                       sym (ns-name ns) (ns-name target-ns)))))
    (intern target-ns sym f)))

(ns foo.car.components.engine)
(defn engine [] (println "engine"))

(ns foo.car.components.transmission)
(defn transmission [] (println "transmission"))

(ns foo.car.components.brakes)
(defn brakes [] (println "brakes"))

(ns foo.car.components
  (:require [foo.utils :refer [export-refs]]))
(export-refs 'foo.car.components '[foo.car.components.engine
                                   foo.car.components.transmission
                                   foo.car.components.brakes])

(ns user
  (:require [foo.car.components :refer [engine transmission brakes]]))
(engine) ;; Prints "engine"
(transmission) ;; Prints "transmission"
(brakes) ;; Prints "brakes"

Whether it's "good practice" or not is up to you. Obviously it has the advantage of splitting code into smaller files with specific functionality, while allowing the import of only a single namespace. The disadvantage is that there's a bit of indirection in where the functions come from, which will make finding the function sources more difficult, and there's more risk of name collisions.

Upvotes: 0

Vlad Filimon
Vlad Filimon

Reputation: 544

It doesn't seem that this feature is provided by Clojure API. You can consider https://github.com/ptaoussanis/encore look for defalias. On the other hand, if you have brakes, transmission and engine as public interfaces and you can use them separately why would you merge them? As opposite, you can provide all definitions in components or even car which will use in turn brakes, transmission and engine. In such way, it is not necessary to expose all components.

Upvotes: 0

Carcigenicate
Carcigenicate

Reputation: 45826

I don't offhand know of a better way, but this way does come with downsides, so take these into consideration when deciding if you want to use this:

  • It doesn't transfer Meta information to the "wrapper", so any docstrings/other information attached to the main function won't show up in IDEs when you use the wrapper.

  • Along the same vein, because the wrapper doesn't have an argument list, if you ctrl+q the wrapper functions, it also won't show the available argument lists of the main function.

Having said that, Seesaw, a major Clojure library that wraps Swing does use this "technique". If I ever forget the docs/arguments of a function that has a "convenience wrapper", I just have to hit ctrl+b twice (in IntelliJ), and it will take me to the original source where I can look it over. It's ironically inconvenient, but I guess that's the price for convenience elsewhere.

To get around these faults, you could write a function (or a macro that wraps def) that transfers Meta information. Considering argument list information is stored as Meta information, that might be enough to overcome the faults.

This answer doesn't really answer your question, so I hope someone else is able to give some insight here. I thought that this was relevant information though.

Upvotes: 1

dpassen
dpassen

Reputation: 1306

You can use:

import-vars

from https://github.com/ztellman/potemkin

Upvotes: 0

Related Questions