Ce sont des conventions communes pour l'utilisation des espaces de noms en Clojure?

Question

Je vais avoir du mal à trouver de bons conseils et de pratiques communes pour l'utilisation des espaces de noms en Clojure. Je me rends compte que les espaces de noms ne sont pas les mêmes que les packages Java donc je suis en train d'essayer de démêler les conventions en Clojure, qui semblent étonnamment difficile à déterminer.

Je pense avoir une assez bonne idée de la manière de répartir les fonctions dans clj des fichiers, et même à peu près comment je veux organiser ces fichiers dans les répertoires. Mais au-delà de que je vais avoir du mal à trouver la mécanique de mon environnement de dev. Certains inter-questions connexes:

1. Puis-je utiliser le même caractère unique des conventions pour Clojure espaces de noms que je voudrais l'utiliser normalement pour les packages Java? [ie en arrière-société-domaine.projet.sous-système]
2. Dois-je enregistrer mes fichiers dans une structure de répertoire qui correspond à mes espaces de noms? [ala Java]
3. Si je dispose de plusieurs espaces de noms, ai-je besoin de compiler l'ensemble de mon code dans un bocal et ajouter à mon classpath pour le rendre accessible?
4. Doit chaque espace de noms de la compilation d'un pot? Ou devrais-je créer un seul bocal qui contient clj code à partir de nombreux espaces de noms?

Merci...

Answer 1

1. Je suppose que c'est ok si vous pensez que c'est utile, mais beaucoup de Clojure projets ne pas le faire -- cf. Compojure (à l'aide d'un niveau supérieur compojure ns et divers compojure.* ns est pour des fonctionnalités spécifiques), Anneau, Leiningen... Clojure lui-même utilise clojure.* (et clojure.contrib.* pour contrib bibliothèques), mais c'est un cas spécial, je suppose.

2. Oui! Vous absolument devez le faire, ou d'autre Clojure ne sera pas en mesure de trouver vos espaces de noms. Notez également que vous il ne faut pas utiliser le trait de soulignement dans les espaces de noms ou le trait d'union dans les noms de fichiers et partout où vous utilisez un trait d'union dans un nom d'espace de noms, vous devez utiliser un trait de soulignement dans le nom de fichier (de sorte que le ns my.cool-project est définie dans un fichier appelé" cool_project.clj dans un répertoire appelé my).

3. Vous devez vous assurer que toutes vos données sont sur le chemin de la classe, mais il n'a pas d'importance si c'est dans un bocal, plusieurs pots, un mélange de pots et des répertoires sur le système de fichiers... tant Qu'il obéit à la bonne conventions de nommage (de votre point de aucune. 2) vous devriez être bien.

   Cependant, ne pas compiler les choses à l'avance si il n'y a pas de raison particulière de le faire-ce qui peut empêcher votre code portable à travers les différentes versions de Clojure sans apporter d'avantages en plus d'une légère amélioration du temps de chargement.

   Vous aurez toujours besoin d'utiliser AOT compilation parfois, notamment dans certaines Java interop scénarios -- la documentation des fonctions de l' / macros mentionne toujours que. Il y a des exemples de choses qui nécessitent AOT en clojure.contrib; je n'ai jamais eu besoin, donc je ne peux pas fournir assez de détails.

4. Je dirais que vous devriez utiliser des bocaux pour les unités fonctionnelles de code. E. g. Compojure et de l'Anneau de empaquetés comme de simples bocaux contenant de nombreux espaces de noms qui, ensemble, composent l'ensemble du paquet. Aussi, clojure.contrib est notamment présentée comme un seul bocal avec de multiples sans rapport avec les bibliothèques; mais que, de nouveau, peut être un cas particulier.

   D'autre part, un seul bocal contenant l'ensemble de votre projet de code de concert avec ses dépendances peuvent parfois être utiles pour le déploiement. Découvrez la Leiningen outil de construction et de ses uberjar " si vous pensez que ce genre de chose peut être utile pour vous.

Answer 2

1. Strictement parlant, n'est pas nécessaire, bien que de nombreux projets Java ont baissé de que la convention, en particulier pour les projets internes ou des Api privées. Afin d'éviter le seul segment des espaces de noms, ce qui aurait pour résultat classfiles générés dans le package par défaut.
2. Oui.

Concernant les 3 & 4, d'emballage et de AOT compilation sont entièrement orthogonale à la question de l'espace de noms des conventions.