L'implémentation de ScrumJet on GitHub (à ce jour) partage des fonctions essentiellement identiques entre les modules de stockage pour les tâches, les catégories et les cartes. Cela a été réalisé en déplaçant le code identique qui fait un usage intensif de la macro ?MODULE en scrumjet_datastore.hrl. Chacun des scrumjet_task.erl, scrumjet_category.erl et scrumjet_board.erl inclut scrumjet_datastore.hrl et n'a aucune fonction définie localement.Comment débugger les fonctions d'includes dans Erlang?
Cela fonctionne très bien quand il n'y a rien de mal. Cependant, si j'ai besoin de déboguer, le débogueur affiche le module vide au lieu du fichier d'en-tête où les fonctions sont définies.
Est-ce que quelqu'un sait comment faire fonctionner le débogueur Erlang pour les fonctions incluses?
Le plus simple serait de simplement copier-coller le code depuis le fichier d'en-tête vers les sources du module et de le recompiler. – Zed
À mon avis, scrumjet_datastore devrait être un module erlang, chaque fonction prenant le nom de la table comme argument supplémentaire. Au lieu de faire appel à ces modules "vides", les appels pourraient être faits à scrumjet_datastore avec le nom de la table passé ... – Zed
Je suis d'accord avec Zed, à moins que vous ne connaissiez une raison spécifique de besoin et .hrl-file et macros, allez avec modules et paramètres normaux autant que vous le pouvez. Cela simplifie beaucoup. Ne vous inquiétez pas pour la performance ou l'inlining pour le moment. –