ist ein custom write möglich?

[Der schöne Günther]

Zitat von 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.

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 von Der schöne Günther:

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 von Der schöne Günther:

... 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 ....

[Dennis07]

Zitat von Der schöne Günther:

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 von Der schöne Günther:

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 von Der schöne Günther:

Du kannst Properties nicht als var - oder 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 von Der schöne Günther:

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 public lesbar, aber z.B. nur 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 von 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 public lesbar, aber z.B. nur 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 von Der schöne Günther:

Kein Mensch braucht die.

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

Zitat von Der schöne Günther:

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 Test.MyValue ist wesentlich performanter und ressourcenschonender als ein Test.GetMyValue , weil der Compiler durch das Feld im read aus dem Test.MyValue dabei ein schlankes Test.fMyValue macht.

Zitat von Der schöne Günther:

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.
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 von Der schöne Günther:

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 von Der schöne Günther:

Du kannst Properties nicht als var - oder out -Parameter übergeben.

Ja nur weil der Compiler wiedermal zu dumm ist.

Zitat von Der schöne Günther:

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 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 property var , property const , property out und property in . Dann soll ebbend eine Referenz aufs Property rein gegeben werden und nicht nur der Wert rein/raus.

Zitat von Der schöne Günther:

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 von Der schöne Günther:

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 von Der schöne Günther:

Oder ich kann, wie man es mit getter- und setter-Methoden sowieso kann, eine Property public lesbar, aber z.B. nur 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 deprecated markieren zu können. Aber geht nunmal nicht.

Zitat von Der schöne Günther:

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 var -Parameter als Zeiger übergeben werden und ein Zeiger auf ein Methodenergebnis nunmal nicht weiterverwertbar ist. Es sind halt keine Variablen.