Daten in Klassen und Records speichern. Zugriffsproblem über mehrere Units

[DieDolly]

Angenommen ich mache aus OptionenA und OptionenB jetzt eine Klasse.
Wo muss welcher Konstruktor hin und wo muss die Referenz gesetzt werden, damit B > A kennt?


Ok ich glaube das hat sich erledigt. Mit Klassen geht es auch nicht. Eben wegen dem zirkuläre Referenzen Problem.
Ich belasse es dabei, dass alles in eine Unit kommt.

[DieDolly]

Um das abzuschließen.

Ich bin so verblieben, dass ich den gesamten Code in einer Unit habe statt über mehrere verteilt.
Da ich nicht überall Getter- und Setterprozeduren brauche und somit bei Read/Write der Feldvariablen bleiben kann, bleibt die Unit doch relativ klein.

Aktuell 450 Zeilen + Leerzeilen (wovon ich einige mehr habe als normal) sowie Kommentarblöcke. Ein Kommentarblock ohne Inhalt besteht bei mir aus 3 Zeilen (davon habe ich 13).
Im Prinzip also rund 400 Zeilen. Davon sind 220 schon für meine Klassendefinition.

[Zacherl]

Ach, bei 400 Zeilen sehe ich da absolut kein Problem

Habe teilweise solche Monstrositäten, die sich daraus ergeben, dass ich eben die von dir beschriebenen Klassenabhängigkeiten habe und zusätzlich noch interne (Klassen-übergreifende) Felder "private" halten möchte. Letzteres (also das was man z.B. unter C++ als friend class oder Java als package -Sichtbarkeit kennt) geht ja auch nur, wenn die Klassen innerhalb der selben Unit deklariert wurden.

Aber da kann man leider nicht viel machen Die Alternative mit "riesiger" Unit - welche alle Interfaces beinhaltet - sieht man schon häufiger, aber bei den Klassen-übergreifenden private Feldern habe ich dann spätestens bei der Implementierung wieder ein Problem und muss alles in eine Unit klatschen.

[DieDolly]

Gut zu wissen, dass meine paar Hundert Zeilen eine Kleinigkeit sind.

In der Roadmap steht, dass irgendwann auch neue Sprachfeatures kommen sollen.
Wird mal höchste Zeit, dass dieses Problem mit den zirkulären Referenzen behoben und auf den neuesten Stand der Dinge gebracht wird.