Compiler Anweisung strict protected

[klgid]

Dachte ich auch - und wurde enttäuscht
Ich habe das wirklich auf Diktat codiert und musste feststellen, dass Delphi (XE7) sich hier anders verhält als erwartet.
Wir (DelHHianer) nehmen an, dass dies ursprünglich so gedacht war, und später "strict" eingeführt wurde, um das erwartete Verhalten (wie bei Java u.a.) zu ermöglichen.

Ehrlich:
Ich wollte es auch nicht glauben!
Musste mich aber eines (Besseren?) Anderen belehren lassen.

Langer Rede, kurzer Sinn:
1. Wenn Ihr Eure Objektfelder privat halten wollt, verwendet STRICT PRIVATE!
2. Prüft noch einmal, worauf abgeleitete Objekte und Helfer Klassen zugreifen können ...

Inzwischen hat Sir Rufo auf einen Beitrag verwiesen.
Kurz überflogen stimmt der mit meiner ursprünglichen Sicht überein.

Versucht bitte einfach einmal, mein unten beschriebenes Szenario nachzuvollziehen - es funktioniert (leider)

[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?

[Stevie]

Zitat von klgid:

Ich habe das wirklich auf Diktat codiert und musste feststellen, dass Delphi (XE7) sich hier anders verhält als erwartet.

Versucht bitte einfach einmal, mein unten beschriebenes Szenario nachzuvollziehen - es funktioniert (leider)

Dann diktier uns mal den Code bitte - das glaube ich dir nämlich nicht - nix für ungut.
Und wenn das so sein sollte, dann isses nen dicker Bock im Compiler.

Edit: Da, alles im grünen Bereich:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Unit1 in 'Unit1.pas',
  Unit2 in 'Unit2.pas';

procedure Main;
var
  bar: TBar;
begin
  Writeln('TFoo.InstanceSize = ', TFoo.InstanceSize); // 12
  Writeln('TBar.InstanceSize = ', TBar.InstanceSize); // 16
  bar := TBar.Create;
  bar.fMyVar := 42;
  Writeln('bar.fMyVar = ', bar.fMyVar);               // 42
  Writeln('bar.MyVar = ', bar.MyVar);                 // 0
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

Delphi-Quellcode:

unit Unit1;

interface

type
  TFoo = class
  private
    fMyVar: Integer;
  public
    property MyVar: Integer read fMyVar;
  end;

implementation

end.

Delphi-Quellcode:

unit Unit2;

interface

uses
  Unit1;

type
  TBar = class(TFoo)
  public
    fMyVar: Integer;
  end;

implementation

end.

[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?