Что такое общие конвенции для использования пространств имен в Clojure?
Я испытываю затруднения при нахождении хорошего совета и общих методов для использования пространств имен в Clojure. Я понимаю, что пространства имен не являются тем же как пакетами Java, таким образом, я пытаюсь чесать конвенции в Clojure, которые кажутся удивительно твердыми определить.
Я думаю, что у меня есть довольно хорошая идея, как разделить функции на clj файлы и даже примерно, как я хотел бы организовать те файлы в каталоги. Но кроме того я испытываю затруднения при нахождении механики для моей dev среды. Некоторые взаимосвязанные вопросы:
- Я использую те же конвенции уникальности для пространств имен Clojure, как я обычно использовал бы для пакетов Java? [т.е. backwards-company-domain.project.subsystem]
- Я должен сохранить свои файлы в структуре каталогов, которая соответствует моим пространствам имен? [Java крыла]
- Если у меня есть несколько пространств имен, я должен скомпилировать весь свой код в банку и добавить его к моему пути к классу для создания его доступным?
- Каждое пространство имен должно скомпилировать в одну банку? Или я должен создать единственную банку, которая содержит код clj от многих пространств имен?
Спасибо...
2 ответа
Я думаю, это нормально, если вы думаете, что это помогает, но многие проекты Clojure этого не делают - ср. Compojure (с использованием compojure ns верхнего уровня и различных compojure. * Ns для определенных функций), Ring, Leiningen ... Сам Clojure использует clojure. * (И clojure.contrib. * Для библиотек contrib), но это особый случай, Я предполагаю.
Да! Вы абсолютно должны сделать это, иначе Clojure не сможет найти ваши пространства имен. Также обратите внимание, что вы не должны использовать подчеркивание в именах пространств имен или дефис в именах файлов, и везде, где вы используете дефис в имени пространства имен, вы должны использовать подчеркивание в имени файла (чтобы ns
my.cool-projectопределен в файле с именемcool_project.cljв каталоге с именемmy).Вы должны убедиться, что все ваши данные находятся в пути к классам, но не имеет значения, находится ли он в банке, в нескольких банках, в смеси банок и каталогов в файловой системе ... Пока он подчиняется правильному соглашения об именах (ваша точка зрения № 2), все должно быть в порядке.
Однако не компилируют заранее, если для этого нет особой причины - это может помешать переносимости вашего кода в различные версии Clojure, не предоставляя никаких преимуществ, кроме незначительного улучшено время загрузки.
Иногда вам все равно придется использовать компиляцию AOT, особенно в некоторых сценариях взаимодействия с Java - это всегда упоминается в документации по соответствующим функциям / макросам. Есть примеры вещей, требующих AOT в clojure.contrib; Мне это никогда не было нужно, поэтому я не могу подробно рассказать.
Я бы сказал, что вы должны использовать jar-файлы для функциональных блоков кода. Например. Compojure и Ring упаковываются как отдельные jar-файлы, содержащие множество пространств имен, которые вместе составляют весь пакет. Кроме того, clojure.contrib упакован как единый jar-файл с несколькими несвязанными библиотеками; но это опять же может быть частным случаем.
С другой стороны, один jar-файл, содержащий весь код вашего проекта вместе с его зависимостями, иногда может быть полезен для развертывания. Посмотрите инструмент сборки Leiningen и его средство uberjar, если вы думаете, что подобные вещи могут быть вам полезны.
- Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
- Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.