ist ein custom write möglich?

[kagi3624]

Hallo,

kann man bei einer property die write (funktion?) umdefinieren?

Also ich möchte ungefähr sowas haben:

property Name : String read fName write trim(fName);

...also dass ich noch auf die Werte noch irgendwelche Funktionen werfen kann.

Danke!

[haentschman]

Moin... :P

Sichwort: Setter :wink:

auf die Schnelle: https://delphi-lernen.de/de/index.php?mid=203&vr=2

[stahli]

Suche mal nach "Getter" und "Setter".

Getter sind lesende Funktionen, die statt einem Lesen eines Propertywertes ausgeführt werden.
Setter sind entsprechend schreibende Prozeduren.

Du Kannst damit z.B. so etwas lösen:

Delphi-Quellcode:

procedure TPerson.setFirstNamne(Value: string);
begin
  fFirstName := Trim(Value);
end;

[Dennis07]

Ich denke er redet davon, in einem Typennachfahr die Read-/Write-Klauseln einer Eigenschaft neu zu definieren, ohne die Eigenschaft zu überschreiben. Und das geht nicht. Du kannst die Signaturen oder Les-/Schreibbarkeit einer Eigenschaft nicht überschreiben, sondern nur deren Sichtbarkeit.

[kagi3624]

Wozu braucht man diese properties dann noch?

[Dennis07]

Zitat:

Zitat von kagi3624 (Beitrag 1456842)

Wozu braucht man diese properties dann noch?

Eigenschaften sind eine Kürzere Schreibweise für Methoden. Sie sind "pseudo-Variablen", die zum Lesen, Schreiben oder beidem entweder auf echte Member-Variablen, oder auf Methoden verweisen.

Eigenschaften können:

1. in ihrer Sichtbarkeit in abgeleiteten Klassen erhöht werden, indem sie ohne einen Typen und ohne eine Read-oder Write-Klausel in der Kindklasse neu deklariert werden
2. auf virtuelle Methoden verweisen, die in Kindklassen überschrieben werden können
3. von der RTTI aus gelesen und analysiert werden und sind somit in Published-Abschnitten zulässig

Das wars. Mehr ist da nicht möglich. Sie sind also so gesehen nur "semantischer Zucker".

[Der schöne Günther]

Zitat:

Zitat von kagi3624 (Beitrag 1456842)

Wozu braucht man diese properties dann noch?

Kein Mensch braucht die. Sie haben keinen Mehrwert und eigentlich nur Nachteile. Die Code-Vervollständigung gibt dir keine Auskunft ob eine Property nur les-, nur schreibbar oder beides ist. Du kannst Properties nicht als

Delphi-Quellcode:

var

- oder

Delphi-Quellcode:

out

-Parameter übergeben.

Das sieht man z.B. auch daran dass Sprachen wie Java keine Entsprechung zu Delphi-Properties haben da man wohl gemerkt hat dass man mit einer einfachen Variable oder getXXX() und setXXX()-Methoden besser fährt.

[hoika]

Hallo,

Zitat:

Wozu braucht man diese properties dann noch

z.B.

property Active: Boolean Read GetActive write SetActive;

Delphi-Quellcode:

procedure SetActive(Wert: Boolean);
begin
  if FActive=Wert then
  begin
    // keine Änderung notwendig
    Exit;
  end;

  if Wert=False then
  begin 
    InternalCloseFile;
    FActive:= False;
    Exit;
  end;

  if FFileName='' then
  begin
    // ev. Log
    Exception.Create('FileName not set');
  end;

  if not FileExists(FFileName) then
  begin
    // ev. Log
    Exception.Create('File does not exist');
  end;

  InternalOpenFile;

  FActive:= True;
end;

Hier wird nicht einfach nur FActive gesetzt, sondern es werden noch einige Randbedingungen geprüft.

[hoika]

Hallo,
und ich benutze die Properties auch sehr gern, um in die Set-Methode Breakpoints zu setzen,
um die Stelle schnell zu finden, wo eine Variable(hier Property) gesetzt wird.

[haentschman]

Delphi-Quellcode:

if Wert=False then

...sowas gehört mit dem Klammerbeutel gepudert. :stupid:

[Der schöne Günther]

Zitat:

Zitat von hoika (Beitrag 1456850)

Hallo,
und ich benutze die Properties auch sehr gern, um in die Set-Methode Breakpoints zu setzen,
um die Stelle schnell zu finden, wo eine Variable(hier Property) gesetzt wird.

Das beantwortet aber nicht welchen Mehrwert die Property gegenüber deiner eh schon vorhandenen set-Methode hat. Außer du tippst gerne viel um nicht aus der Übung zu kommen.

[hoika]

Hallo,
naaa ;)

Ich kann dann ja so schöne Sätze coden wie

Delphi-Quellcode:

if not Table.Active then
begin
  Table.Active:= True;
end;

anstatt zu schreiben

Delphi-Quellcode:

if not Table.GetActive then
begin
  Table.SetActive(True);
end;

Und die Published Properties kann ich im Object-Inspector setzen und in der DFM mit speichern.

[freimatz]

Zitat:

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

Das beantwortet aber nicht welchen Mehrwert die Property gegenüber deiner eh schon vorhandenen set-Methode hat. Außer du tippst gerne viel um nicht aus der Übung zu kommen.

Weil
a) damit zusammenkommt was zusammengehört und
b) das mit dem MMX eh das schneller geht als ohne property

[TBx]

Zitat:

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

... keinen Mehrwert und eigentlich nur Nachteile. ...
Das sieht man z.B. auch daran dass Sprachen wie Java keine Entsprechung zu Delphi-Properties haben ...

Naja, irgend einen Grund muss es ja haben, dass so "verstaubte", "uralte" Sprachen wie c# und Swift durchaus Properties haben .... :gruebel::gruebel:

[Dennis07]

Zitat:

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

Kein Mensch braucht die. Sie haben keinen Mehrwert und eigentlich nur Nachteile.

"Brauchen" ist Relativ. Nein, sie sind (bis auf Published-Eigenschaften) nirgendwo zwingend notwendig. Aber sie verkürzen Code enorm und machen ihn an vielen Stellen übersichtlicher, und vereinfachen gleichzeitig die Zugriffsbeschränkung auf private Member.

Zitat:

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

Die Code-Vervollständigung gibt dir keine Auskunft ob eine Property nur les-, nur schreibbar oder beides ist.

Das ist richtig, aber kein Problem der Properties sondern ausschließlich eines der Code-Vervollständigung.

Zitat:

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

Du kannst Properties nicht als

Delphi-Quellcode:

var

- oder

Delphi-Quellcode:

out

-Parameter übergeben.

Ja, logischerweise kannst du das nicht. Wie soll das denn auch funktionieren? Es sind ja keine Variablen, sondern müssen zu Funktionen/Prozeduren kompatibel sein. Keine Ahnung wie du dir da vorstellst, dass man sie übergeben können soll.

Zitat:

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

Das sieht man z.B. auch daran dass Sprachen wie Java keine Entsprechung zu Delphi-Properties haben da man wohl gemerkt hat dass man mit einer einfachen Variable oder getXXX() und setXXX()-Methoden besser fährt.

"Sprachen wie Java" haben das. Nur halt Java (als so ziemlich einzige Sprache, die mir jetzt spontan einfällt) hat das nicht. C#, C++ und sogar JavaScript haben sehr wohl Eigenschaften, die mehr oder weniger genau wie in Delphi funktionieren.

[Der schöne Günther]

Mit alt hat das nichts zu tun. Ich sehe nur echt keine Daseinsberechtigung in Delphi. Dass es in C++ Properties gibt wäre mir jetzt neu. C# hat auch Properties, hier sind sie aber wenigstens nicht so sinnlos wie in Delphi.

Beispielsweise sehe ich in der IDE ob ich eine Property setzen darf und nicht erst wenn der Compiler mir das um die Ohren wirft. Oder ich kann, wie man es mit getter- und setter-Methoden sowieso kann, eine Property

Delphi-Quellcode:

public

lesbar, aber z.B. nur

Delphi-Quellcode:

protected

schreibbar machen.

Außerdem gibt es beispielsweise Element-Initalisierer, da machen die Properties wirklich Spaß.

Aber in C# kann man leider auch keine Properties als ref/out-Parameter übergeben, das ist schade.

[TurboMagic]

Zitat:

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

Mit alt hat das nichts zu tun. Ich sehe nur echt keine Daseinsberechtigung in Delphi. Dass es in C++ Properties gibt wäre mir jetzt neu. C# hat auch Properties, hier sind sie aber wenigstens nicht so sinnlos wie in Delphi.

Beispielsweise sehe ich in der IDE ob ich eine Property setzen darf und nicht erst wenn der Compiler mir das um die Ohren wirft. Oder ich kann, wie man es mit getter- und setter-Methoden sowieso kann, eine Property

Delphi-Quellcode:

public

lesbar, aber z.B. nur

Delphi-Quellcode:

protected

schreibbar machen.

Außerdem gibt es beispielsweise Element-Initalisierer, da machen die Properties wirklich Spaß.

Aber in C# kann man leider auch keine Properties als ref/out-Parameter übergeben, das ist schade.

Du könntest diese Ideen ja mal als Wünsche ins QP schreiben...

[einbeliebigername]

Hallo,

Zitat:

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

Kein Mensch braucht die.

Also ich brauche die Properties. Da ich Mensch bin, habe ich hiermit deine Aussage wiederlegt.

Zitat:

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

Sie haben keinen Mehrwert

Oh doch, haben sie. Ein kleines Beispiel:

Delphi-Quellcode:

type
  TTest= class
  strict private
    fMyValue: Boolean;
    
    procedure SetMyValue(const aMyValue: Boolean);
  public
    property MyValue: Boolean read fMyValue write SetMyValue;
  end;

var
  Test: TTest;

Der lesende Zugriff auf

Delphi-Quellcode:

Test.MyValue

ist wesentlich performanter und ressourcenschonender als ein

Delphi-Quellcode:

Test.GetMyValue

, weil der Compiler durch das Feld im read aus dem

Delphi-Quellcode:

Test.MyValue

dabei ein schlankes

Delphi-Quellcode:

Test.fMyValue

macht.

Zitat:

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

und eigentlich nur Nachteile.

Ja es gibt Nachteile. Aber nur weil der Compiler zu dumm ist. Wie oben gezeigt haben die schon Vorteile. Auch das Geter und Seter sinnvoll zusammengefast sind, ist schon ein gewaltiger Vorteil.

Delphi-Quellcode:

property TmpTmp: Boolean read Schöne write Schlecht;

Denn wer bringt dem Compiler bei, dass deine GetXXX / SetXXX immer mit Get / Set anfangen müssen und XXX bei beiden gleich sein muss? Und vor allem wie?

Auch und dann der Objektinspektor, den es ohne Properties bestimmt nicht geben würde.

Zitat:

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

Die Code-Vervollständigung gibt dir keine Auskunft ob eine Property nur les-, nur schreibbar oder beides ist.

Aber nur weil die zu dumm ist. Der Compiler hat ja auch die Info. Warten wir mal den Umbau der darunter liegenden Technologie ab.

Zitat:

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

Du kannst Properties nicht als

Delphi-Quellcode:

var

- oder

Delphi-Quellcode:

out

-Parameter übergeben.

Ja nur weil der Compiler wiedermal zu dumm ist.

Zitat:

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

Außer du tippst gerne viel um nicht aus der Übung zu kommen.

Delphi-Quellcode:

var vTmp: Boolean;
begin
  vTmp:= Test.GetMyValue;
  DoTest(vTmp);
  Test.SetMyValue(vTmp);

Wieso soll ich nochmal so viel Unnützes tippen? Da stelle ich doch lieber mal eine Frage zur Anregung. Wieso kann der Compiler aus dem gut lesbaren

Delphi-Quellcode:

DoTest(Test.MyValue)

nicht selbstständig ein schönes

Delphi-Quellcode:

  var Dummy= Test.fMyValue;
  DoTest(Dummy);
  Test.SetMyValue(Dummy);

machen?

Und schöne wäre bei Parametern auch ein

Delphi-Quellcode:

property var

,

Delphi-Quellcode:

property const

,

Delphi-Quellcode:

property out

und

Delphi-Quellcode:

property in

. Dann soll ebbend eine Referenz aufs Property rein gegeben werden und nicht nur der Wert rein/raus.

Zitat:

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

Das sieht man z.B. auch daran dass Sprachen wie Java keine Entsprechung zu Delphi-Properties haben da man wohl gemerkt hat dass man mit einer einfachen Variable oder getXXX() und setXXX()-Methoden besser fährt.

Ach was interessiert mich diese eine Sprache. Die hat viel zu viele Nachteile.

[Dennis07]

Zitat:

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

Dass es in C++ Properties gibt wäre mir jetzt neu. C# hat auch Properties, hier sind sie aber wenigstens nicht so sinnlos wie in Delphi.

Die Properties in C# sind ziemlich exakt genau so wie in Delphi. In C++ gibt es seit Version 11 Eigenschaften, die genau wie in Delphi funktionieren.

Zitat:

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

Oder ich kann, wie man es mit getter- und setter-Methoden sowieso kann, eine Property

Delphi-Quellcode:

public

lesbar, aber z.B. nur

Delphi-Quellcode:

protected

schreibbar machen.

Das wäre in der Tat schön, also quasi partielle Eigenschaften. Aber syntaktisch schwer machbar. Ebenso wäre es schön, Eigenschaften als

Delphi-Quellcode:

deprecated

markieren zu können. Aber geht nunmal nicht.

Zitat:

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

Aber in C# kann man leider auch keine Properties als ref/out-Parameter übergeben, das ist schade.

Weil das, wie schon gesagt, nunmal rein logisch nicht möglich sein kann, da

Delphi-Quellcode:

var

-Parameter als Zeiger übergeben werden und ein Zeiger auf ein Methodenergebnis nunmal nicht weiterverwertbar ist. Es sind halt keine Variablen.