Compiler Anweisung strict protected

[Der schöne Günther]

Ich verstehe das "leider" immer noch nicht.

private und protected heißt: "(Unterklassen und )selbe Unit"
Mit "strict" heißt es: "(Unterklassen)"

Und ein Klassenhelfer fühlt sich an keine Sichtbarkeitsmodifikatoren gebunden. Was ist denn daran jetzt so abenteuerlich?

[mkinzler]

Ohne strict it alles innerhalb der selben Unit public. Die Sichtbarkeit wirkt sich nur über Unitgrenzen aus. Mit strict erzwingt man das auch innerhalb der Unit.

[klgid]

Zitat von Der schöne Günther:

Ich verstehe das "leider" immer noch nicht.

private und protected heißt: "(Unterklassen und )selbe Unit"
Mit "strict" heißt es: "(Unterklassen)"

Und ein Klassenhelfer fühlt sich an keine Sichtbarkeitsmodifikatoren gebunden. Was ist denn daran jetzt so abenteuerlich?

Abenteuerlich ist daran, dass ich eine Berechnungsklasse schreibe und meine Berechnungsgrundlagen als PRIVATE markiere, damit mir niemand meine Berechnungen verändern kann, PRIVATE aber leider nicht UNVERÄNDERBAR bedeutet. STRICT PRIVATE tut dies dann ...

Diese Diskussion ist natürlich zu 99.9% philosophisch, d.h. es geht darum, inwieweit sich Delphi an anderen Sprachen orientiert.
"private" in JAVA ist PRIVATE, "private" in Delphi ist ...

Ich poste nachher noch entsprechenden Source - aktuell läuft auf meinem System gerade ein Update ...

[Der schöne Günther]

Gemessen an anderen vergleichbaren Sprachen sind die Sichtbarkeitsmodifikatoren in Delphi etwas... seltsam, ja. Aber neu und aufregend ist das ja eigentlich nicht, denn die waren ja schon immer so.

Ich bin ehrlich gesagt auch immer zu faul das "strict" mitzutippen. Im Endeffekt aber auch egal da mir andere Sprachen (z.B. Java) das "Pro Unit nur eine Klasse" mit Gewalt angewöhnt haben.

[himitsu]

Zitat von klgid:

PRIVATE aber leider nicht UNVERÄNDERBAR bedeutet. STRICT PRIVATE tut dies dann ...

Und dann kommt Einer daher und umgeht dennoch das PRIVATE wieder, indem er einen Class Helper oder die erweiterte RTTI benutzt,
wobei man die RTTI ordnungsgemäß und geziehlt deaktivieren könnte.

Aber gerade bei den Class Helpern versteh ich einfach nicht, warum das ist ist, denn im Prinzip sollte das eechtlich eher wie ein Nachfahre behandelt werden.

[Sir Rufo]

Das Gejammer hier ist ja kaum zum Aushalten

Über was regt ihr euch eigentlich auf? Dass ihr euch nicht umfassend informiert habt bzgl. dem strict ? Oder überfordert es euch?

Da gibt man euch die Möglichkeit an die Hand die Zugriffe ganz fein zu steuern (quasi bis auf Nano-Ebene herunter) und ihr flennt hier rum, wie ein Kleinkind, dem man den Schnuller geklaut hat.

Ja, es ist richtig, dass man sich Gedanken machen muss ... (wie denken?!?) ... welche Zugriffe strikt untersagt werden müssen, unter allen Umständen.

Wo darf also kein class helper oder innerhalb der gleichen Unit - das ist ja nun eh lachhaft, wer Zugriff auf die Unit hat und an das Feld xy nicht dran kommt, der ändert einfach den Sourcecode, somit ist das da nur Selbstschutz, bzw. ein Statement "ich habe damals entschieden, da darf keiner sonst drauf zugreifen, denke nach warum" - irgendwas anderes darauf zugreifen, dann packt es einfach in den strict private .

Dafür wurde es geschaffen. Das ist die Intention. Genau wie es die Intention ist, dass begin end einen Code-Block bildet. Brauchst du es, benutze es, wenn nicht lass es. Wenn du es aber brauchen würdest, es aber nicht benutzt hast, was macht man dann? Ja man schreibt das dann einfach dort hin.

@himitsu

Der class helper wird wie ein Nachfahre in der gleichen Unit der gehelpten Klasse behandelt. Ansonsten käme der auch an den strict private Teil.

Soll ich euch noch was Nettes zeigen?

Delphi-Quellcode:

type
  TFoo = class
  strict private
    FValue : string;
  public
    procedure Bar( AFoo : TFoo );
    property Value : string read FValue;
  end;

procedure TFoo.Bar( AFoo : TFoo );
begin
  // beschreiben der strict private Variablen einer anderen Instanz
  AFoo.FValue := Self.FValue;
end;

[Der schöne Günther]

Zitat von Sir Rufo:

// beschreiben der strict private Variablen einer anderen Instanz

Spätestens hier ist Schluss! Das grenzt ja schon an Hausfriedensbruch. Ungeheuerlich dass hier noch keine gesetzlichen Regelungen existieren.

[Sir Rufo]

Zitat von Der schöne Günther:

Zitat von Sir Rufo:

// beschreiben der strict private Variablen einer anderen Instanz

Spätestens hier ist Schluss! Das grenzt ja schon an Hausfriedensbruch. Ungeheuerlich dass hier noch keine gesetzlichen Regelungen existieren.

Genau, denn derjenige, der diese Klasse konstruiert hat, den muss man ja jetzt davor schützen (äh, wovor eigentlich )

Bin ich eigentlich hier im Forum für betreutes Wohnen oder doch noch in einem Forum für Programmierer?

[TiGü]

Volle Zustimmung an Sir "Gunnery Sergeant" Rufo!

[Daniel]

Zitat von Sir Rufo:

Bin ich eigentlich hier im Forum für betreutes Wohnen oder doch noch in einem Forum für Programmierer?

Wir nennen es gern "betreutes Programmieren".
Dennoch muss auch ich zugeben, dass auch mir die Konsequenzen von "private" erst im Laufe von Jahren klar geworden sind. Als ich mit Delphi begonnen hatte, war mir das offen gestanden relativ schnurz. Da war das dann schon ein "aha"-Moment, als aus "private" plötzlich "strict private" wurde. Wenngleich ich es in realen Projekten eher weniger einsetze - vermutlich aus Gewohnheit und weil "private" in einem Atemzug mit "protected" und "public" schneller geschrieben ist.