Haskell Modul Namenskonventionen

Question

Wie sollte ich meine Haskell Module für ein Programm, keine Bibliothek, und benennen sie in einer Hierarchie ordnen?

Ich mache einen Ray Tracer namens Luminosity. Zuerst hatte ich diese Module:

Jedes Modul war in Ordnung für sich, aber ich fühlte mich wie diese Organisation fehlte.

Zuerst legte ich jedes Modul unter Luminosity, also zum Beispiel Vector war jetzt Luminosity.Vector (ich nehme an, das ist Standard für ein Haskell-Programm?).

Dann dachte ich: Vektor und Farbe sind unabhängig und könnten wiederverwendet werden, also sollten sie getrennt werden. Aber sie sind viel zu klein, um Bibliotheken zu werden.

Wohin sollten sie gehen? Es gibt bereits (auf Hack) eine Data.Vector und Data.Colour, also sollte ich sie dort hinstellen? Oder wird das Verwirrung stiften (auch wenn ich sie mit meinen anderen lokalen Importen gruppiere)? Wenn nicht, sollte es Luminosity.Data.Vector oder Data.Luminosity.Vector sein? Ich bin mir ziemlich sicher, dass ich beides gesehen habe, obwohl ich vielleicht zufällig ein Projekt mit einer unkonventionellen Struktur betrachtete.

Ich habe auch eine einfache TGA Bild Exporteur (Export), die unabhängig von Luminosity sein kann. Es scheint der richtige Ort wäre Codec.Image.TGA, aber wieder sollte Luminosity irgendwo drin sein und wenn ja, wo?

Es wäre schön, wenn Structure of a Haskell project oder ein anderes Wiki dies erklärt.

Answer 1

Zunächst einmal habe ich jedes Modul unter Luminosity

Ich denke, das ein guter Schachzug war. Es verdeutlicht allen, die den Code lesen, dass diese Module speziell für das Luminosity Projekt erstellt wurden.

Wenn Sie ein Modul mit der Absicht schreiben, eine bestehende Bibliothek zu simulieren oder zu verbessern oder eine Lücke zu füllen, in der Sie glauben, dass eine bestimmte generische Bibliothek fehlt, dann löschen Sie in diesem seltenen Fall das Präfix und benennen Sie es generisch. Ein Beispiel dafür ist, wie das Paket pipesControl.Monad.Trans.Free exportiert, weil der Autor aus irgendeinem Grund nicht mit vorhandenen Implementierungen von Free Monads zufrieden war.

Dann dachte ich, Vector und Color sind ziemlich unabhängig und könnten wiederverwendet werden, also sollten sie getrennt werden. Aber sie sind zu klein, um sie in eine Bibliothek zu trennen (125 bzw. 42 Zeilen). Wohin sollten sie gehen?

Wenn Sie nicht über eine separate Bibliothek machen, dann lassen sie wahrscheinlich bei Luminosity.Vector und Luminosity.Colour. Wenn Sie separate Bibliotheken erstellen, senden Sie eine E-Mail an die Zielgruppe dieser Bibliotheken und sehen Sie, wie andere Personen glauben, dass diese Bibliotheken benannt und kategorisiert werden sollten. Ob Sie diese in separate Bibliotheken aufteilen oder nicht, hängt ganz von Ihnen ab und davon, wie viel Nutzen diese getrennten Bibliotheken Ihrer Meinung nach für andere Menschen bringen könnten.

Answer 2

Sofern Ihr Programm wirklich groß ist, organisieren Sie nicht die Module in einer Hierarchie. Warum nicht? Denn obwohl Computer in der Hierarchie gut sind, sind es die Menschen nicht. Menschen sind gut in sinnvollen Namen. Wenn Sie gute Namen wählen, können Sie problemlos 150 Module in einem flachen Namensraum verwalten.

Ich fühlte mich wie [eine flache Namensraum] Organisation fehlte.

Hierarchische Organisation ist kein Selbstzweck. Um das Aufteilen von Modulen in eine Hierarchie zu rechtfertigen, benötigen Sie einen Grund. Gute Gründe haben meist damit zu tun, dass Informationen versteckt oder wiederverwendet werden. Wenn Sie das Verstecken von Informationen einbringen, befinden Sie sich auf halbem Weg zu einem Bibliotheksdesign, und wenn Sie über Wiederverwendung sprechen, bauen Sie effektiv eine Bibliothek auf. Ein großes Programm in ein "kleineres Programm plus Bibliothek" zu verwandeln, ist eine gute Strategie für die Software evolution, aber es sieht so aus, als ob Sie gerade erst anfangen, und Ihr Programm ist noch nicht groß genug, um sich so zu entwickeln.

Diese Probleme sind weitgehend unabhängig von der Programmiersprache, die Sie verwenden. Ich empfehle, einige Arbeiten von David Parnas zu Produktlinien und Programmfamilien zu lesen, und auch das von Matthias Blume unterschätzte Papier Hierarchical Modularity. Diese Arbeiten geben Ihnen einige konkretere Ideen darüber, wann die Hierarchie einen Zweck erfüllt.