Co powinno i nie powinno być w pliku nagłówkowym Erlang (.hrl)?

Question

Jestem nieco zdezorientowany, do czego powinien być używany plik .hrl. Rozumiem, że pliki .hrl mogą zawierać dowolny poprawny kod Erlang i że przy użyciu dyrektywyzasadniczo wstawi się kod w pliku .hrl do dowolnego modułu, który go zawiera.

Jaki kod jest odpowiedni do umieszczenia w tych plikach .hrl? Zasady programowania Erlang jest podać następujące dane w odniesieniu do zapisów:

Jeśli rekord ma być używany w kilku modułów, jego definicja powinna być umieszczona w pliku nagłówkowym (z przyrostkiem .hrl), który znajduje się z modułów.

W rezultacie utworzyłem zwyczaj robienia tego w moim kodzie. Jednak lubię umieszczać rzeczy takie jak instancjonowanie i funkcje porównawcze dla rekordów, jak również definicje typów w moich nagłówkach (ponieważ jest to coś, co robiłbym w C). Czy to zła forma? Czy zamiast tego typy powinny być eksportowane z pliku .erl, nawet jeśli są używane w wielu modułach? Wydaje się, że nie ma dokumentacji dotyczącej najlepszych praktyk dotyczących nagłówków Erlang.

Answer 1

LIke C, instrukcja include dosłownie dodaje zawartość dołączonego pliku do pliku erl. Dlatego umieszczenie dowolnego kodu w plikach hrl spowoduje, że kod będzie kopiowany wszędzie, gdzie go zawrzesz. Doprowadziłoby to do niepotrzebnego powielania funkcji w każdym module Erlang.

Umieszczałbym każdy rzeczywisty kod Erlang we własnym module ERL oraz wszelkie definicje rekordów, specyfikacje typów lub popularne makra w plikach hrl. Definicje rekordów i specyfikacje typów nie są kompilowane do plików binarnych, więc można je bezpiecznie umieszczać w wielu plikach.

Answer 2

Używam plików hrl do przechowywania różnych urządzeń do wykorzystania w moich testach jednostkowych. Nie lubię używać ich w rzeczywistych kodach produkcyjnych do niczego. Posiadanie tej samej funkcji zaimportowanej w różnych lokalizacjach utrudnia ustalenie kodu. Bardziej wskazane jest posiadanie tego kodu w oddzielnym module i wyraźne wyeksportowanie go. Rodzaje można również eksportować jawnie za pomocą dyrektywy -export_type.

Nie podoba mi się nawet dzielenie się z nim płytami (mimo że jest to jedyny sposób udostępniania rekordów). W tym celu wolę, aby moduł zarządzał tylko tą metodą z odpowiednimi funkcjami get i set. Udostępnione rekordy to katastrofa, która czeka, aby się wydarzyć, i sprawia, że ​​aktualizacje kodu są trudniejsze.

Krótko mówiąc, nie używaj ich do niczego ważnego.

Answer 3

Zwykle umieszczasz rzeczy w .hrl, które chcesz udostępniać między modułami, zwykle rejestrują definicje i makra. Rzeczy, które mają być wyłącznie lokalne dla modułu, którego nie można wstawić do pliku . Tak więc czysto lokalna definicja rekordu, na przykład stan lokalny na serwerze, nie byłaby dostępna w .hrl, ale tylko w module definiującym serwer. To samo dotyczy definicji makr. Zawsze należy unikać niepotrzebnego ujawniania informacji wewnętrznych.

Ponieważ plik dołączany jest bezpośrednio wstawiany do pliku włączającego, wówczas każdy kod w nim zawarty zostanie zduplikowany w każdym module, który go zawiera. Na ogół nie chcesz tego robić.