AW: Compiler Anweisung strict protected
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) :( |
AW: Compiler Anweisung strict protected
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? |
AW: Compiler Anweisung strict protected
Zitat:
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. |
AW: Compiler Anweisung strict protected
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.
|
AW: Compiler Anweisung strict protected
Zitat:
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 ... |
AW: Compiler Anweisung strict protected
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. |
AW: Compiler Anweisung strict protected
Zitat:
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. :wall: |
AW: Compiler Anweisung strict protected
Das Gejammer hier ist ja kaum zum Aushalten :roll:
Über was regt ihr euch eigentlich auf? Dass ihr euch nicht umfassend informiert habt bzgl. dem
Delphi-Quellcode:
? Oder überfordert es euch?
strict
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
Delphi-Quellcode:
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
class helper
Delphi-Quellcode:
.
strict private
Dafür wurde es geschaffen. Das ist die Intention. Genau wie es die Intention ist, dass
Delphi-Quellcode:
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.
begin end
@himitsu Der
Delphi-Quellcode:
wird wie ein Nachfahre in der gleichen Unit der gehelpten Klasse behandelt. Ansonsten käme der auch an den
class helper
Delphi-Quellcode:
Teil.
strict private
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; |
AW: Compiler Anweisung strict protected
Zitat:
|
AW: Compiler Anweisung strict protected
Zitat:
Bin ich eigentlich hier im Forum für betreutes Wohnen oder doch noch in einem Forum für Programmierer? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz