Polymorphie und Interfaces in Delphi

[Sir Rufo]

Zitat von himitsu:

Hmmm, das ist jetzt komisch.

Delphi-Quellcode:

type
  IMyIntf = interface
    function Getter: Integer;
    procedure Setter(i: Integer);
    property Prop: Integer read Getter write Setter;
  end;

Ich weiß jetzt nicht mehr welche Delphi-Version das war, aber damals wurde der Getter und Setter nicht ausgeblendet, was XE jetzt aber macht.

Delphi-Quellcode:

type
  IInnerMyIntf = interface
    function Getter: Integer;
    procedure Setter(i: Integer);
  end;
  IMyIntf = interface(IInnerMyIntf)
    function Abc: Integer;
  end;

Dafür wird im IMyIntf der Getter/Setter jetzt doch angezeigt.

Hmmmmmmmmm.

logischerweise, weil ja da nirgendwo eine property ist, die diese Methoden benutzt

[himitsu]

Damals wurde das halt auch angezeigt, obwohl es die Property dazu gab.

Das war auch der einzige Grund, warum ich überhaupt mit diesen vererbten Interfaces gearbeitet hatte.
Also kann ich mir nun den Spaß ersparen, was mir aber nicht aufgefallen ist, da ich das aus "Erfahreung" halt auch in aktuelleren Projekten gleich so gemacht hatte. Obwohl es jetzt zwar immernoch funktionierte, auch wenn aus einem anderem Grund.

[Sir Rufo]

Zitat von himitsu:

Damals wurde das halt auch angezeigt, obwohl es die Property dazu gab.

Aber zum Schluss hast du dich gewundert warum die jetzt angezeigt werden obwohl du keine property dafür hast

[himitsu]

Jupp, denn damals wurde alles aus den Vorfahren nicht angezeigt, womit ich jetzt nicht damit gerechnet hätte, daß man die nun sieht, wenn der Property weg ist.

Getter/Setter von Property wurden im selben Interface angezeigt, aber nichts aus dem Vorfahren.

[Mikkey]

Zitat von Der schöne Günther:

Zitat von Patito:

Zitat von Mikkey:

Dein Beispiel zieht nicht, weil die Delphi-Syntax keine zwei Implementierungen einer Funktion der Vorfahrenklasse erlaubt.

Schau Dir die Syntax zum implementieren und deligieren von Interfaces noch mal genau an....

Da spielt nur mein etwas älteres XE nicht mit, nur die Variante mit zwei voneinander abgeleiteten Klassen s.o. funktioniert.

Zitat:

Ein realitätsnahes Beispiel hierfür will mir aber auch nicht einfallen.

Mir auch nicht. Selbst wenn so etwas aus irgendeiner Notwendigkeit gemacht werden würde, hielte ich es für extrem schlechten Stil, wenn eine Methode gleichen Namens einer Objektinstanz verschiedene Dinge tut.

[TiGü]

Zitat von himitsu:

Ich weiß jetzt nicht mehr welche Delphi-Version das war, aber damals wurde der Getter und Setter nicht ausgeblendet, was XE jetzt aber macht.
Dafür wird im IMyIntf der Getter/Setter jetzt doch angezeigt.

Das war auch der einzige Grund, warum ich überhaupt mit diesen vererbten Interfaces gearbeitet hatte.
Also kann ich mir nun den Spaß ersparen, was mir aber nicht aufgefallen ist, da ich das aus "Erfahreung" halt auch in aktuelleren Projekten gleich so gemacht hatte. Obwohl es jetzt zwar immernoch funktionierte, auch wenn aus einem anderem Grund.

Das hatten wir doch schon im Januar?!
Siehe: http://www.delphipraxis.net/178780-v...ml#post1245525

Meinen damaligen Post gelesen, aber nicht verstanden???

[himitsu]

Alzheimer?

[Stevie]

Zitat von Neutral General:

Hab ich was verpasst oder sollte das nicht prinzipiell funktionieren?
Wenn ich TKlasse explizit zusätzlich IBaseInterface implementieren lasse (was ja eigentlich unnötig ist) dann funktionierts.

Hat das einen Grund (bin ich blöd?) oder ist Delphi blöd?

Zitat von Der schöne Günther:

Hatten wir kürzlich schon mal (suche gleich den Link): Ja, es ist eigentlich unnötig. Aber du musst das Parent-Interface trotzdem in der Typdefinition angeben. Sonst merkst du noch nichtmal zur Laufzeit mit Supports(..) dass es eigentlich IBaseInterface kann!
Delphi-Style. Gefällt mir auch nicht.

Dafür können wir uns bei Microsoft und einem historischen OLE2 Bug von denen bedanken.
Warum genau wird in diesem Artikel erklärt (hatte ich in dem anderen Thread auch schon verlinkt)

[Patito]

Zitat von Der schöne Günther:

[...]
Ein realitätsnahes Beispiel hierfür will mir aber auch nicht einfallen.

Ein Beispiel wären z.B. Methoden zum Schreiben eines Logfiles im Basis-Interface:

Delphi-Quellcode:

IBase = interface(IInterface)
  procedure SetLogfile(const FileName: TFileName);
  procedure WriteLog(const LogInfo: String);
end;

IRead = interface(IBase);
IWrite = interface(IBase);

Die Interfaces zum Schreiben der Log-Infos sind in IRead und IWrite dieselben, aber Reader und Writer
könnten unterschiedliche Logfiles verwenden.

Dass man Interface-Methoden beliebig auf eigene Implementierungen mit anderem Namen umbiegen kann ist
ein recht zentrales Feature von Interfaces. Es löst die ganzen Probleme, die man in anderen Programmiersprachen
bei rein Klassen-basierter Mehrfachvererbung hat (C++).
Mehr oder weniger ist das mal ein Featur, bei dem man mal von einem echten Vorteil von Delphi sprechen könnte.