¿Cuáles son las convenciones más comunes para usar espacios de nombres en Clojure?

Question

Tengo problemas para encontrar buenos consejos y prácticas comunes para el uso de espacios de nombres en Clojure. Me doy cuenta de que los espacios de nombres no son lo mismo que los paquetes de Java, así que estoy tratando de descubrir las convenciones en Clojure, que parecen sorprendentemente difíciles de determinar.

Creo que tengo una muy buena idea de cómo dividir las funciones en archivos clj e incluso más o menos cómo me gustaría organizar esos archivos en directorios. Pero más allá de eso, tengo problemas para encontrar la mecánica para mi entorno de desarrollo. Algunas preguntas interrelacionadas:

1. ¿Utilizo las mismas convenciones de exclusividad para los espacios de nombres Clojure que normalmente usaría para los paquetes Java? [es decir, backwards-company-domain.project.subsystem]
2. ¿Debo guardar mis archivos en una estructura de directorio que coincida con mis espacios de nombres? [ala Java]
3. Si tengo varios espacios de nombres, ¿necesito compilar todo mi código en un jar y agregarlo a mi classpath para que sea accesible?
4. ¿Debería cada espacio de nombres compilar en un contenedor? ¿O debería crear un único contenedor que contenga código clj de muchos espacios de nombres?

Gracias ...

Answer 1

1. supongo que está bien si usted piensa que ayuda, pero muchos proyectos Clojure no lo hace - cf. Compojure (usando componentes de alto nivel y varios compojure. * Ns para funcionalidad específica), Ring, Leiningen ... Clojure usa clojure. * (Y clojure.contrib. * Para bibliotecas contrib), pero ese es un caso especial, Supongo.

2. Sí! Usted absolutamente debe, o de lo contrario Clojure no podrá encontrar sus espacios de nombres. También tenga en cuenta que no debe utilizar el guión bajo en nombres de espacios de nombres o el guión en nombres de archivos y donde use un guión en un nombre de espacio de nombres, debe usar un guión bajo en el nombre de archivo (para que ns my.cool-project se defina en un archivo llamado cool_project.clj en un directorio llamado my).

3. Debes asegurarte de que todo tu material está en el classpath, pero no importa si está en un jar, en varios jars, en una mezcla de jarras y directorios en el sistema de archivos ... Mientras obedezca las convenciones de nomenclatura correctas (su punto n. ° 2) debería estar bien.

   Sin embargo, no lo hacen compilar cosas antes de tiempo si no hay una razón particular para hacerlo - esto puede evitar que su código de ser portable a través de varias versiones de Clojure sin proporcionar ningún beneficio, además de un tiempo de carga ligeramente mejorada .

   A pesar de todo, necesitará utilizar la compilación AOT, especialmente en algunos escenarios de interoperabilidad de Java; la documentación de las funciones/macros relevantes siempre menciona eso. Hay ejemplos de cosas que requieren AOT en clojure.contrib; Nunca lo he necesitado, así que no puedo proporcionar muchos detalles.

4. Yo diría que debe usar jarras para unidades funcionales de código. P.ej. Compojure y Ring se empaquetan como contenedores individuales que contienen muchos espacios de nombres que juntos componen todo el paquete. Además, clojure.contrib está especialmente empaquetado como un único contenedor con múltiples bibliotecas no relacionadas; pero eso nuevamente puede ser un caso especial.

   Por otro lado, un solo contenedor que contiene todo el código de su proyecto junto con sus dependencias puede ser útil ocasionalmente para la implementación. Consulte the Leiningen build tool y su instalación 'uberjar' si cree que ese tipo de cosas pueden serle útiles.

Answer 2

1. En sentido estricto, no es necesario, aunque muchos proyectos de Java que han caído convenciones, así, sobre todo para los proyectos internos o APIs privadas. Sin embargo, evite los espacios de nombres de un solo segmento, lo que daría como resultado que los archivos de clases se generen en el paquete predeterminado.
2. Sí.

En cuanto a 3 & 4, el empaquetado y la compilación AOT son totalmente ortogonales a la cuestión de las convenciones de espacios de nombres.