PureBoard

Hi Leute,

beim Arbeiten mit mehreren Dateien (oder auch einer) gibt es ja bei ungünstiger Include-Reihenfolge die Möglichkeit der Declare-Anweisung um benötigte Prozeduren bereits vor ihrer Definition zu beschreiben.

Gibt es auch einen Trick bei Modulen? Ich bin kein großer Fan von dieser Common-Module Lösung wie in der Purebasic-Hilfe beschrieben, da man hier meiner Meinung nach wieder etwas unsauber wird

Hier mal ein Minimalbeispiel: Würde man dieses Programm kompilieren, so gibt es einen Fehler, da die Prozedur Mod_A::ShowTextInB() auf eine Variable (bzw. auf ein Modul) zugreifen soll, die es zu diesem Zeitpunkt ja noch gar nicht gibt.
Vertauscht man die beiden Module Mod_A und Mod_B in ihrer Reihenfolge, so lässt sich das Programm einwandfrei ausführen.

Im Moment habe ich den Fall, dass ich mehrere Module habe, die gegenseitig auf Variablen/Prozeduren von sich zugreifen sollen...hier gibt es also keine ideale Reihenfolge. Gelöst habe ich es aktuell wieder mit einem Common-Modul, aber das ist ja nicht wirklich das Ziel (saubere Trennung), wenn man Module verwendet...es kommt mir sogar eher gepfuscht vor (wie damals zu Goto-Zeiten)

Stehe ich vielleicht auf dem Schlauch und jemand hat einen guten Tip für mich?
Ich verwende üblicherweise pro Modul eine eigene Datei, falls das noch relevant ist.


Vielen Dank und schöne Grüße,
Andi

...Gelöst habe ich es aktuell wieder mit einem Common-Modul...

Das ist der Weg.
Ansonsten muss man erst unter die Philosophen gehen, und die Henne - Ei frage klären.

Bisonte hat geschrieben: 06.07.2023 07:33

...Gelöst habe ich es aktuell wieder mit einem Common-Modul...

Das ist der Weg.
Ansonsten muss man erst unter die Philosophen gehen, und die Henne - Ei frage klären.

https://m.focus.de/gesundheit/news/ei-o ... 48082.html

Die Frage ist geklärt . Aber ich finde die Lösung über common module auch unschön.

Die Lösung über ein Common-Modul ist meiner Meinung nach die einzig richtige und wird in der Objektorientierung in Form von Vererbung gelebt. Das es nicht die schönste Art und Weise ist, wie es in Purebasic realisiert wurde, ist schon klar. Aber letzten Endes hilft es auch nichts, nur weil man es hässlich findet, sich drum herum zu hacken.

Meine Regeln für die Programmierung mit Modulen (oder wie in PHP mit statischen Klassen) sind die, das ich 2 Typen von Modulen verwende. Zum einen unabhängige für sich geschlossene, die direkt im Programmfluss verwenden können und die Grundlegende Funktionalität beinhalten. Zum anderen die Common-Module, die als Verbindungsglied zwischen mehreren Modulen dienen. Diese benötige ich aber persönlich extrem selten, weil deren Aufgabe es ist, die Funktionalitäten zweier oder mehrerer Module in einem zentralen Modul zu bündeln. Hier könnte man ein Loggingmodul als Beispiel nennen, welches in alle anderen Modulen, die etwas loggen sollen, eingebunden wird.

Für die Reihenfolge der Includes sind am Ende nur zwei Dinge zu beachten. Alle Includes in der Regel zuerst in den Quellcode packen. Und als zweites darauf achten, zuerst die Basis-Module und dann die Common-Module einzuhängen. Wenn man das so strikt trennt, dann kann nichts schief gehen und die Frage nach der Reihen folge stellt sich garnicht erst. Wenn man aber ein Common-Modul von einem weiteren Common-Modul abhängig gemacht hat, dann sollte meiner Meinung nach Reihenfolge das kleinste Problem sein. Das größere Problem liegt da eher im Ist-Zustand

Bisonte hat geschrieben: 06.07.2023 07:33 Das ist der Weg.

Zuviel The Mandalorian geschaut?

Zum Thema:
Meine Module sind eigentlich immer autark, ich brauche kein Modul, das auf ein anderes Modul (vielleicht noch mit der Hilfe eines dritten Moduls?) zugreifen kann.

Tatsächlich brauchte ich es nur einmal, dass war dann aber wegen eigener Faulheit

HeX0R hat geschrieben: 06.07.2023 20:15

Bisonte hat geschrieben: 06.07.2023 07:33 Das ist der Weg.

Zuviel The Mandalorian geschaut?

Erwischt

Hi,

sorry für die etwas späte Antwort und vielen Dank für die Tips und Meinungen.
Ich habe mich jetzt mittlerweile damit abgefunden bzw. angefreundet, Module eher nur für meine externen Bibliotheken zu verwenden.
Also Dateien, die ich völlig alleinständig in mein beliebiges Projekt einbinden kann. In solchen Fällen kann ich das Modul auch autark gestalten.

Wenn es jedoch um Programmteile geht (also um Teile ausschließlich für das laufende Projekt), habe ich mich jetzt eher von den Modulen abgewendet...das mit dem Common-Modul ist mir da echt irgendwie ein Dorn im Auge
Mit einzelnen Projektdateien und entsprechenden Präfixe vor den Prozeduren/Variablen geht ist es für mich irgendwie schöner anzusehen

Bei Visual Basic 6 war das noch cool...da war es völlig egal, an welcher Stelle man etwas deklariert (also von der Reihenfolge her)...es war im Code immer bekannt. Es gab einfach nur Private Bereiche, allgemeine Bereiche und öffentliche Bereiche (Module)...und zudem noch ein wenig Ordnung durch etwas OOP.

Möglicherweise stehe ich ja auf dem sprichwörtlichen Schlauch, aber sobald man einmal realisiert hat, daß man Module-Dateien splitten kann (in einen Declaration-Teil und einen Implementation-Teil), ist das ganze doch recht einfach? Im Mini-Beispiel einfach die DeclareModule vor die Implementation (= Module) setzen.

Ich mache solche Sachen wie unten In vielen Programmen... "Unsauber" kommt mir das nichts vor!?!

Hi kpeters58,

danke für den Tipp, das wusste ich echt noch nicht, dass man die Module Splitten kann.
Man braucht dann zwar immer eine Header-Datei, aber das ist ja nichts ungewöhnliches...das werde ich mir bestimmt mal zu Nutze machen.