Wieso ist property nicht änderbar ?

[Winni]

Vielleicht ist der Record aber auch schlicht nicht der ideale Datentyp für einen Property Setter.

Hi!

Indeed.
Alle visuellen Komponenten haben left,top,width,height.

Die kann man einzeln setzen.
Oder mit setBounds bzw. setSize mehrere auf einmal.

Winni

[Winni]

Hi!

Ich denk immer noch zu altmodisch.

Trect kann das doch alles inzwischen:

Code: Alles auswählen

TRect = packed
  record
  ......
public
       property Height: Longint read getHeight write setHeight;
       property Width : Longint read getWidth  write setWidth;
       property Size  : TSize   read getSize   write setSize;
       property Location  : TPoint read getLocation write setLocation;
       case Longint of
         0: (Left,Top,Right,Bottom : Longint);
         1: (TopLeft,BottomRight : TPoint);
         2: (Vector:TArray4IntegerType);
       end;              
end;

Winni

[fliegermichl]

Hi,

nichtsdestotrotz kannst du auf Einzelbestandteile einer property vom Typ TRect nicht schreibend zugreifen.
Beispiel:

Code: Alles auswählen

type
 TMyDingen = class
 private
  fFrameSize : integer;
  fSize : TRect;
  function GetInnerframe : TRect;
  function SetInnerframe(const Value : Trect);
 public
  property Innerframe : TRect read GetInnerframe write SetInnerframe;
 end;
 
 function TMyDingen.GetInnerframe : TRect;
 begin
  with Result do
  begin
   Left := fSize.Left + fFrameSize;
   Top := fSize.Top + fFrameSize;
   Right := fSize.Right - fFrameSize;
   Bottom := fSize.Bottom - fFrameSize;
  end;
 end;
 
 procedure TMyDingen.SetInnerframe(const Value : TRect);
 begin
  with Value do
  begin
   fSize.Left := Left - fFrameSize;
   fSize.Top := Top - fFrameSize;
   fSize.Right := Right + fFrameSize;
   fSize.Bottom := Bottom + fFrameSize;
  end;
 end;
 

Wo ist hier die Adresse von Innerframe?

[PascalDragon]

Funktioniert wunderbar:

Du hast nicht richt richtig gelesen:

Code: Alles auswählen

program tproptest;

{$mode objfpc}{$H+}

uses
  Types;

type
  TTest = class
  private
    FRect: TRect;
    function GetRect: TRect;
  public
    property Rect1: TRect read GetRect;
    property Rect2: TRect read FRect;
  end;

function TTest.GetRect: TRect;
begin
  Result := FRect;
end;

var
  t: TTest;
  p: PLongInt;
begin
  t := TTest.Create;
  try
    p := @t.Rect1; // Error: Variable identifier expected
    p := @t.Rect2; // ok
  finally
    t.Free;
  end;
end.

[Warf]

Man kann das folgende machen:

Code: Alles auswählen

procedure Foo;
type
  PRect = ^TRect;
begin
  PRect(@SomeObj.Rect)^.Top := 42;
end;

Das gesagt. das funktioniert nur (wie PascalDragon schon erwähnt hat) wenn die property direkt ein Feld referenziert. Außerdem, wenn die property einen setter hat, kompiliert das zwar, ist aber letztendlich kaputter code, weil der setter umgangen wird (und damit potentiell error checking, seiteneffekte, etc).

Beispiel:

Code: Alles auswählen

TTest = class
  FInternalMemory: Array of Array of Byte;
  FSize: TPoint;
  procedure SetSize(const AValue: TPoint);
...
  property Size: TPoint read FSize write SetSize;
...

procedure TTest.SetSize(const AValue: TPoint);
begin
  SetLength(FInternalMemory, AValue.X, AValue.Y);
  FSize := AValue;
end;

Wenn man hier jetzt via pointern FSize ändert, würde die interne memory nicht gereallocated werden, und man wäre in einem kaputten state der über kurz oder lang wahrscheinlich in einer segfault endet. Damit lassen sich übringens auch read only properties beschreiben.

Also auch wenn es möglich ist solche schweinereien über pointer zu machen, wäre ich da ganz ganz vorsichtig. Wenn ein setter dahinter steht, oder schlimmer noch, die property read only ist, dann macht man definitiv etwas das die komponente eigentlich nicht erlauben will

[theo]

@Warf: Das wurde hier eigentlich schon gesagt
Die eigentliche Frage lautet. "Wie hältst du es mir den Regeln der OOP"?
Wenn man versucht, die OOP auszutricksen wie Winni, kann man es auch gleich sein lassen und C oder ASM schreiben.
Erinnert mich irgendwie an den Arduino Thread.

[Mathias]

Ich habe das Problem umgangen, in dem ich auch TRect verzichtete.
Ich habe nun 4 property Left, Width, etc.

[Warf]

Wenn man versucht, die OOP auszutricksen wie Winni, kann man es auch gleich sein lassen und C oder ASM schreiben.
Erinnert mich irgendwie an den Arduino Thread.

Winni hat ja nicht mal wirklich OOP ausgetrickst. Das man die addresse von Properties holen kann ist ein Feature. Das ist zwar natürlich kaputtes design, aber dank delphi kompatibilität ist kaputtes design auch ein feature im FPC.
Das wirklich kaputte was Winni macht ist das er der meinung ist er kennt die interne representation des records besser als der Compiler. Wie in meinem beispiel gezeigt ist den kompiler zu fragen das er von einem pointer auf einen record auf ein element zu zu greifen, eine zeile ist. Winni's code ist komplizierter, und muss annahmen über die interne represenation treffen. Das ist schlechtes programm design, aber hat nix mit OOP zu tun, den records und pointer gibts bereits schon deutlich länger als OOP, und solchen code würde man z.b. auch nicht in C schreiben. Tatsächlich muss ich hier mal C verteidigen, denn das ganze ist in C sogar auch nicht erlaubt, da es undefiniertes verhalten ist. Das casten von pointer typen nicht definiert ist (außer von typisiertem pointer nach void* und anders rum), in diesem fall ist also das casten von einem record pointer auf einen integer pointer undefiniertes verhalten und wäre damit kein valider C code.

[theo]

Winni hat ja nicht mal wirklich OOP ausgetrickst.

Du hast natürlich recht, dass hier auch Ungereimtheiten auf tieferer Ebene vorliegen.
Dennoch wurde hier primär versucht, den Property Setter zu "umschiffen".
Meiner Meinung nach findet OOP hauptsächlich im Kopf des Programmierers statt.
Inwieweit der Compiler/Interpreter OOP erzwingen sollte, darüber kann man streiten.
Wer keinen Bock auf OOP hat, der muss ja nicht, aber dann soll er auch konsequent sein und sie nicht versuchen zu hintergehen.

[Mathias]

Ohne OOP geht es heutzutage kaum mehr. Ausser bem Embeded Systemen und Kondolenanwendungen.

[Winni]

Hej!

Ich wollte hier keine Generaldebatte anzetteln.

Die Situation war eigentlich trivial:

Ein StringGrid. Beim Programmstart sortiere ich schon mal die erste Spalte.
Davon bekommt die property SortColumn aber nix mit, sie steht immer noch auf -1,
weil sie nur auf UserClicks reagiert: Designfehler.

Realität und SortColumn widersprechen sich jetzt.
SortColumn ist außerdem readony.
Nun wollte ich - um den User nicht zu verwirren - den Sotierstatus darstellen.
Sonst ist erst beim zweiten Mausklick auf den Header zwecks Sotierens
wieder alles korrekt.

Da stand ich nun und die property gab mir keine Chance zum Eingreifen.
Dazu hätte ich erstmal ne aufgebohrte Tochterklasse bauen müssen.
Viel zu viel Action für das Problem!

C'est la.

Winni

[Timm Thaler]

Ohne OOP geht es heutzutage kaum mehr. Ausser bem Embeded Systemen und Kondolenanwendungen.

Dazu hätte ich gern mal eine Definition, wo OOP anfängt. Bei manchen ist OOP ja schon, wenn man paar Variablen in ein Record packt und das weiterreicht. Bei anderen darf kein Programmablauf mehr erkennbar sein.

Ich tu mich da immer schwer zu sagen, das ist jetzt hier OOP.

[Mathias]

Ein Record ist definitiv keine OOP, genau so wenig wie ein type helper.
OOP muss Vererbungen enthalte, sowie überschreibare Methoden.
Ein sehr gutes Beispiel für OOP ist FreeVision.

[Winni]

Hi!

Records waren schon in N. Wirths erster Version von Pascal vorhanden also ~ 1970.
Haben dann viele Sprachen abgekupfert und - damit es nicht so peinlich ist - gleich anders
genannt.

Über Objectorientierung dachten zu dem Zeitpunkt nur die "Verrückten" von Simula und Smalltalk nach.
Die OOP wurde erst Ende der 80er bis Anfang der 90er Mode. 1987 kam Oberon. 1995 kam Delphi.

Nur um das mal zeitlich einzuordnen.

Winni

[Mathias]

Turbo Pascal hast du noch vergessen. Das kannte auch schon Objekte.