"Fehler" bei Überschreiben von Properties

[3_of_8]

Morgen.

Ich habe gerade eine recht... seltsame Entdeckung bei der Überschreibung von Properties gemacht.

Es sieht so aus, als würde der Compiler sich gar nicht erst überlegen, ob er die Property der Oberklasse oder die der Unterklasse nimmt. Ich kann das Vorgehen des Compilers zwar verstehen, aber eigentlich müsste er doch bei einer Situation wie der in meinem Testprojekt einen eigenen Eintrag in der VMT anlegen und dann da nachschauen... :gruebel:

Folgende Klassen:

Delphi-Quellcode:

type
  TA=class
  protected
    FFoo: Integer;
  public
    property Foo: Integer read FFoo write FFoo;
  end;

  TB=class(TA)
  public
    procedure SetFoo(AFoo: Integer);
    property Foo: Integer read FFoo write SetFoo;
  end;

implementation

procedure TB.SetFoo(AFoo: Integer);
begin
  FFoo:=AFoo;
  showmessage('Wuppdi');
end;

Jetzt folgender Code:

Delphi-Quellcode:

var a: TB;
begin
  a:=TB.Create;
  a.Foo:=42;
end;

Es kommt wie erwartet die Messagebox. Kleine Änderung:

Delphi-Quellcode:

var a: TA;
begin
  a:=TB.Create;
  a.Foo:=42;
end;

Keine Messagebox. Der Compiler beschreibt einfach FFoo und ruft SetFoo nicht auf.

Mich würde auch interessieren, ob sich das bei neueren Delphiversionen reproduzieren lässt.

[mkinzler]

Du hast zwar ne Instanz von TB erzeugt, diese wird aber einer Referenzvariable für TA zuhewiesen, deshalb wird auch die Implementierung von TA verwendet.

[Hawkeye219]

Hallo Manuel,

VMT = Virtual Method Table :wink:

Wo hast du eine virtuelle Methode?

Gruß Hawkeye

[3_of_8]

Das ist es ja: Die soll der Compiler implizit anlegen. Sinngemäß würde ich sagen: Wenn ich die Property in der Unterklasse überschreibe und eine Instanz dieser Unterklasse habe, dann soll der Compiler auch die überschriebene Property aufrufen.

[mkinzler]

Die Variable ist aber vom Typ der Oberklasse.

[3_of_8]

Ja, aber die Instanz ist eine Instanz der Unterklasse. Nur der Instanzenpointer ist halt als Pointer auf die Instanz der Oberklasse deklariert.

Für mich ist es leicht sinnlos, wenn TB(a).Foo:=42; ein anderes Ergebnis bringt als a.Foo:=42.

EDIT: Mir ist klar, dass das kein Bug ist, sondern "as designed", aber ich halte das trotzdem für nicht OOP-konzeptgemäß.

[JasonDX]

Zitat:

Zitat von 3_of_8

ich halte das trotzdem für nicht OOP-konzeptgemäß.

Ist es aber. Alle Aufrufe von Members, welche keinen Eintrag in der VMT haben, werden von der Klasse aufgerufen, unter der die Variable deklariert, nicht instanziert wurde.
Einfach aus dem Grund, weil ansonsten zur Compile-Time nicht entschieden werden kann, welche Methode ausgefuehrt werden soll.

greetz
Mike

[3_of_8]

Das ist mir klar. Deswegen sagte ich ja auch, der Compiler soll in diesem Fall einen VMT-Eintrag anlegen, damit er es weiß.

[Elvis]

Zitat:

Zitat von 3_of_8

Das ist mir klar. Deswegen sagte ich ja auch, der Compiler soll in diesem Fall einen VMT-Eintrag anlegen, damit er es weiß.

Delphi kennt keine virtuellen Properties.
Case closed. ;)

[3_of_8]

Klar. Aber Delphi kennt virtuelle Methoden, also könnte der Compiler einen virtuellen Setter anlegen anstatt das "write FFoo" wörtlich zu nehmen. Ich habe jedenfalls relativ lange gebraucht, um diesen Fehler zu finden, vor allem deshalb, weil ich an der falschen Stelle gesucht habe. Ich habe mir gedacht "ich habe hier die Property überschrieben, also passt das" und habe Hunderte andere Codezeilen und Tutorials und Beispielunits durchwühlt.

Naja, ich glaube in Zukunft deklariere ich immer Settermethoden für Properties, die überschrieben werden.