Ich vermisse Konstanten erst im Konstruktor initialisieren zu können

[Der schöne Günther]

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210767)

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

Wir SIND gefährlich! 8-)

[stahli]

[nicht so ganz ernst gemeint aber es sollte funktionieren]
Man könnte noch ein privates Flag mit führen: ConstIsNil:=True;

Wird die "Konstante" über einen Setter definiert, wird das Flag auf False gesetzt.
Weitere Zuweisungen über den Setter führen zu einem BlueScreen.

Damit dürfte das Überschreiben der Konstante vermieden werden (außer jemand umgeht bewußt die Kindersicherung).
[/nicht so ganz ernst gemeint aber es sollte funktionieren]

[SubData]

Zitat:

Zitat von stahli (Beitrag 1210774)

[...]
Man könnte noch ein privates Flag mit führen: ConstIsNil:=True;
[...]

Bääh, nee, bitte nicht. Das halte ich ja mal für wirklich dreckig.
Dann lieber sauber kommentieren.

Edit: Ja, ich hab gesehen, dass du das nicht ganz ernst meinst, aber Neulinge klauen sich ja leider immer die blödsten (nicht böse gemeint) Ideen :)

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210767)

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

Nee, die schreiben zusätzlich Unittests und wenn das ganz wichtig ist, dann wird das der erste Testfall

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1210766)

Ich finde auch, man sollte nur hinreichend intelligente Programmierer an die Sourcen lassen.

Das ist aber extreme Arbeitskraftverknappung!

Gruß
K-H

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210762)

Mir ging es eher darum, dass jemand nicht aus Versehen später etwas ändert, was sich rein logisch nicht ändern kann. Wie beispielsweise die Adresse auf die ein Gerät antworten soll.

Beim Programmieren sollte man das Gehirn eingeschaltet lassen, tut man das nicht, bekommt man eben unerwartete Ergebnisse.

Wenn du es wirklich absichern willst, setze den Wert im Konstruktor und schreibe dazu eine Prüfsumme des Wertes in ein weiteres privates Feld. Wenn dann jemand beides ändert, ist er selbst schuld. Aber eine versehentliche Änderung könntest du so später erkennen.

[Furtbichler]

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Den Quelltext gibst Du einfach nicht weiter, dann hat sich die Sache erledigt. Dein Problem ist ja ein generelles Problem, welches so gar nicht lösbar ist. Oder hab ich mal wieder irgendwas verpasst?

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1210824)

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Den Quelltext gibst Du einfach nicht weiter, dann hat sich die Sache erledigt. Dein Problem ist ja ein generelles Problem, welches so gar nicht lösbar ist. Oder hab ich mal wieder irgendwas verpasst?

Delphi-Quellcode:

strict private

nur die direkte Klasse kann darauf zugreifen. Weder innerhalb der Unit noch Ableitungen können darauf zugreifen

[DeddyH]

Zitat:

Zitat von Furtbichler (Beitrag 1210824)

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Sicher? Nach meiner Kenntnis ist sie nur in der Klasse sichtbar, zu der sie gehört, aber nicht in abgeleiteten Klassen, selbe Unit oder nicht.

[edit] *Boah eyh*, roter Kasten wieder kaputt (schon das 2. Mal heute) [/edit]