Идиоматический подход для структурирования Clojure исходный код

Question

Меня интересует, как люди структурируют свой исходный код Clojure.

используется для Java, я довольно хорошо знаком с парадигмой одного класса в файл исходного кода, связывая все определения данных и методов с соответствующими комментариями и примечаниями и т.д.

Однако Clojure предлагает намного больше гибкости и я не знаю, как я должен структурировать мой проект (вероятно, в конечном итоге, как приложение размера среднего, возможно, 5000 линий с тремя или четырьмя различными подсистемами)

в частности, я боролся с:

• Какие руководящие принципы я должен использовать для определить, должен ли код находиться в одном пространстве имен или разделен на разные пространства имен?
• Должен ли каждый протокол/тип данных иметь собственное пространство имен + исходный файл с соответствующим набором функций?
• Когда мне нужно использовать другие пространства имен или использовать другие пространства имен?

Answer 1

Я тоже из фона Java, а также довольно немного Ruby и немного Go. Вот что я делаю в данный момент, около месяца в Clojure:

• Я имею в виду пространства имен в качестве семантической единицы, это код, который идет вместе для определенной цели, как тип данных и операции в теме.

У меня есть два соглашения для пространств имен против файлов:

• Для низковата единиц, которые соответствуют комфортно в одном файле (я использую ~ 1000 строк, как предел, когда файл должен быть разделен) я одно пространство имен для каждого файла, а путь к каталогу плюс имя файла совпадает с именем пространства имен. Это хорошо, на мой взгляд, в Java, это делает поиск пространства имен из файла или наоборот ветерок.
• Для больших единиц, которым требуется несколько файлов, я использую соглашение Go: пространство имен соответствует пути к каталогу, и все файлы в каталоге имеют одно и то же пространство имен. В этих случаях я обычно назначаю первичный файл с фиксированным именем ('main'), который загружает и взаимодействует с другими.

В качестве примера пространства имен у меня есть синтаксический анализатор, который читает формат и преобразует его в HTML. У меня есть одно пространство имен для синтаксического анализатора (семантический блок) и несколько файлов в каталоге, разделенных на подфункции: Lexer, парсер, преобразование HTML и основной файл, содержащий первичный публичный API для использования синтаксического анализатора.

Я бы не стал автоматически использовать одно пространство имен для каждого типа данных, это зависит от области действия типа данных. Возможно, это большой. Но для такого типа данных, как Point, с двумя полями и несколькими функциями, я предпочел бы использовать его в более общем пространстве имен, таком как Geometry.

Требовать против использования:

• Требовать с соответствующим коротким псевдонимом почти везде.
• Это также позволяет повторно использовать имена ядер: мой тип данных специального назначения имеет операцию «получить», чтобы она соответствовала картам; использование требует конфликта нет: «get» - это ядро ​​Clojure, «tree/get» - это один для моего типа данных.
• Я использую «использовать» только для того, что я считаю «расширениями ядра», например, когда я создаю свою собственную «карту-если», которая представляет собой карту и фильтр, свернутые в один.