Property read wird autom. erzeugt

[Jumpy]

Hallo,

in diesmal D2010 habe ich eine "write only" property:

property SC:TSC write fSC;

Wann immer ich eine neue Property oder Funktion definiere und dann mit Strg+Shift+C alles anlegen lassen will schreibt er mir noch ein read in die Property und dass zudem in falscher Weise hinter das write:

property SC:TSC write fSC read fSC;

Und beim nächsten kompilieren gibts deswegen mecker.

Woher kommt das? Darf man keine "write only" property haben?

[DeddyH]

Das scheint eher ein Bug in der Klassenvervollständigung zu sein. Ich habe das gerade in meinem XE ausprobiert, da passiert das nicht, kann mich aber erinnern, dass ich dieses Verhalten auch schon einmal festgestellt habe. Ob der Fehler nun in XE behoben wurde oder ob es vielleicht an den Erweiterungen (GExperts, DDevExtensions, IDE FixPack 5.4) liegt, weiß ich allerdings nicht.

[Jumpy]

In D6 hab ich das Problem auch nie gehabt (oder ich hatte nie WriteOnly-Proeprtys).

[Bernhard Geyer]

Für einen Wert den man nur setzen kann halte ich ein Property für den falschen weg.
Was spricht gegen eine Methode?

Property würde ich nur bei (write/)read Werte einsetzen.

[DeddyH]

Das hat aber doch mit dem Verhalten der Klassenvervollständigung nichts zu tun. Wenn ich der Meinung bin, ich brauche eine WriteOnly-Property, dann soll diese bitteschön nicht verschlimmbessert werden.

[Furtbichler]

Zitat von Jumpy:

Darf man keine "write only" property haben?

Es macht keinen Sinn bzw. ist kein guter Stil. Das die Delphi-Vervollständigung da Mist macht, steht auf einem anderen Blatt.

Wieso es kein guter Stil ist? Eine 'Variable' (eine Property ist ja nichts anderes, nur mit stringenter Get/Set-Logik) die man beschreiben kann, aber nie wieder lesen, ist keine Variable. Oder allgemein gesehen: Eine Eigenschaft ist mindestens lesbar, damit sie eine Eigenschaft ist. Beschreibbar wird sie, wenn das Verändern der Eigenschaft entweder nur unter bestimmten Fällen möglich ist (Setter-Logik), oder andere Effekte hat (Setter-Funktionalität). Mittlerweile geht man sogar dazu über, public/protected Variablen als Property zu implementieren, sodaß die Setter-Logik=null ist.

Wenn Du die 'Eigenschaft' nur verändern willst, aber nie nie nicht lesbar, dann mach daraus eine Methode, denn -wie gesagt- Du änderst keine Eigenschaft deines Objektes, sondern führst eine Aktion aus. Oder du implementierst einen backing store (privates Feld) und lässt sie halt auslesen.

@DeddyH: Das ist richtig, so ist/war das Murks.

[Jumpy]

Habt ja recht, war Käs. Ist schließlich Freitag

Was ich da mache ist einen Methodenzeiger setzen und man kann da eigentlich auch ruhig das read drin lassen. Aber irgendwie ware ich der Meinung ich brauch das (von aussen) nicht auslesen (innerhalb der Klasse hatte ich das so implementiert, dass ich direkt auf die Variable (if Assigned(fSC) then...) gucke) und habs weggelassen, womit dann der ganze Ärger angefangen hat.

Aber blöd von der IDE isset doch. Aber vielleicht hat die heute auch bloß Freitag...

[Jumpy]

Aber wo wir gerade von schlechtem Stil bei Properties reden...

Es gibt ja viele Klassen, wo mittels einer Methode Add was hinzugefügt wird, z.B.
Stringlist.Add('SomeString') .

Ich habe aber in unserem Framework auch schon eingige Klassen gesehen (nicht gemacht), bei denen das Add eine Property mit dahinterliegender Setter-Prozedur ist, die dann was an eine Liste oder sonstwas anhängt, das sieht dann so aus:

IrgendeineKlasse.Add:='SomeString' .

Das finde ich einerseits manchmal ganz praktisch, andererseits, hab ich das Problem, wenn ich zuviel mit einer solchen Klasse gemacht habe und dann wieder einmal mit einer Stringlist arbeite, ärgere ich mich über die lästigen Klammern. Dabei ist das doch eigentlich der Standard.

[DeddyH]

Also, mich würde das verwirren.

[Jumpy]

Das mein ich ja. Wenn man viel damit gearbeitet hat, dann kommt man mit dem durcheinander was man als üblichen Standard kennt. Insofern ist das schon eine schlechte Verwendung einer Poperty.
Aber in dem Fall muss ich wohl damit leben, da wenn man die betroffenen Klassen ändert, an unheimlich vielen Stellen die Verwendung der Klasse geändert werden müsste.