Idiomatyczne podejście do struktury kodu źródłowego Clojure

Question

Jestem zainteresowany tym, jak ludzie konstruują swój kod źródłowy Clojure.

wykorzystywane do Javy, jestem dość obeznany z paradygmatem jednej klasy na plik kodu źródłowego, łączenie wszystkie definicje danych i metody z odpowiednich uwag i adnotacji itp

Jednak Clojure oferuje dużo większą elastyczność i nie jestem pewien, w jaki sposób powinna wyglądać struktura projektu (mogą skończyć jako średniej wielkości aplikacji, może 5000 wiersze z trzech lub czterech różnych podsystemów)

W szczególności mam zmaga się z:

• Jakich wytycznych należy użyć, aby określić, czy kod powinien znajdować się w pojedynczej przestrzeni nazw, czy powinien być rozdzielony na różne przestrzenie nazw?
• Czy każdy protokół/typ danych powinien mieć własny obszar nazw + plik źródłowy z powiązanym zestawem funkcji?
• Kiedy należy korzystać z innych przestrzeni nazw?

Answer 1

Jestem również z tła Java, wraz z całkiem sporo Ruby i trochę Go. Oto, co robię w tej chwili około miesiąca do Clojure:

• myślę o nazw jako semantycznej jednostki, to kod, który idzie razem do określonego celu, podobnie jak typ danych i operacji na tym.

Mam dwie konwencje nazw vs plików:

• Dla niewielkich jednostek, które mieszczą się wygodnie w jednym pliku (używam ~ 1000 linii jako granica gdzie plik powinien być podzielony) Mam jeden obszar nazw na plik, przy czym ścieżka katalogu plus nazwa pliku są takie same jak przestrzeń nazw. Jest to dobre w Javie, jak sądzę, sprawia, że ​​znajdowanie przestrzeni nazw z pliku lub odwrotnie to pestka.
• W przypadku większych jednostek, które wymagają kilku plików, używam konwencji Go: Przestrzeń nazw jest zgodna ze ścieżką do katalogu, a wszystkie pliki w katalogu mają tę samą przestrzeń nazw. W takich przypadkach zwykle przypisuję główny plik o stałej nazwie ("main"), który ładuje i współdziała z innymi.

Jako przykład przestrzeni nazw, mam analizator składni, który odczytuje format i konwertuje go do formatu HTML. Mam pojedynczy obszar nazw dla analizatora składni (jednostki semantycznej) i kilka plików w katalogu podzielonych na podfunkcję: Lexer, analizator składni, konwersję HTML i główny plik zawierający podstawowy publiczny interfejs API do używania analizatora składni.

Nie używałbym automatycznie jednej przestrzeni nazw na typ danych, zależy to od zakresu typu danych. Jeśli to duży, być może. Ale dla typu danych, takiego jak Point, z dwoma polami i kilkoma funkcjami, wolałbym podporządkować go bardziej ogólnej przestrzeni nazw, takiej jak Geometria.

Wymagaj vs. użytku:

• Wymagaj z odpowiednio krótkim alias niemal wszędzie.
• Pozwala to również na ponowne użycie nazw rdzenia: Mój typ danych drzewa specjalnego ma operację "get", aby pasowała do map; używając require nie ma konfliktu: "get" to core Clojure get, "tree/get" jest tym dla mojego typu danych.
• Używam "use" tylko do tego, co uważam za "podstawowe rozszerzenia", jak wtedy, gdy tworzę własną "mapę-jeśli", która jest mapą i filtrem w jednym.