Class Helper for Interface

[Stevie]

Zitat von TiGü:

Aber warum nicht einfach ILoggerHelper = interface(ILogger) ?

Und, wie bekomm ich dann die Methoden von ILoggerHelper aufgerufen, wenn ich nur ILogger implementiere?
Ja, Dekorator bauen, etc... aber darum gehts nicht.

Außerdem könnte ich, wären die helper vernünftig implementiert auch mehrere gleichzeitig aktiv haben, mach das mal mit Vererbung

Eine mögliche Syntax die ich mir auch vorstellen könnte wäre sowas (woher ich das wohl habe...):

Code:

procedure EnterMethod(extends logger: ILogger; const methodName: string);

Und die kann man dann so aufrufen:

Code:

logger.EnterMethod('foo')

Simpler Syntaxzucker also. Und wenn ich das gerade richtig überblicke dürften dort auch alle Regeln von normalen Routinen (sprich, welche Methode ist im Scope, Overload resolution etc) greifen.

[Der schöne Günther]

Bei der Gelegenheit könnte man gleich noch eine Diskussion über, seit Java 8 vorhandene, Standard-Implementierungen für Interfaces anstoßen: Ein Interface kann eine Standard-Implementierung einer Methode sowie statische Methoden vorgeben. Im Endeffekt geht das ja in eine stark ähnliche Richtung.

Würdet ihr, so etwas gerne in Delphi sehen wollen? Ich dachte erst "Was für ein Quatsch" aber in der Zwischenzeit bin ich auch über ein paar Fälle gestolpert wo man das hätte gebrauchen können...

[himitsu]

Zitat von Der schöne Günther:

aber in der Zwischenzeit bin ich auch über ein paar Fälle gestolpert wo man das hätte gebrauchen können...

Wenn man es so nimmt, dann wollte ich diesesmal genau das.

Im Grunde geht es genau um das, wozu diese Helper erfunden wurden. Das "erweitern" der Funktionen, von irgedwas (Klasse/Record/Typ), ohne diesen Typen direkt zu verändern.


Bei Klassen kann man einfach vererben, aber bei Interfaces geht das nicht, denn dort muß man das "Objekt" hinter dem Interface verändern/kapseln und Funktionsaufrufe an das originale Interface weiterreichen.

Man kann ein eigenes Objekt schreiben, daß beim QueryInterface die Zugriff auf das/die originalen Interfaces weitergibt, aber rückwärts geht das nicht, daß das "fremde" Objekt mein Interface nicht kennt.
Dazumal sind das zwei getrennten Objekte und die Referenzzählung/Freigabe ist nicht lösbar, ohne das andere Interface komplett zu kapseln.

[Sir Rufo]

Unter Delphi ist das mit den Interface Helpern doch uninteressant, denn die Interfaces unterstützen keine Generics

Delphi-Quellcode:

IFoo<T> = interface
  function AsType<TResult> : TResult; // <- Zonk
end;

Mit einem record drumherum ist das dann wieder kein Problem (ist ja in Spring4D auch so vorhanden )

Delphi-Quellcode:

Foo<T> = record
  class operator implicit ( a : IFoo<T> ) : Foo<T>;
  function AsType<TResult> : TResult;
end;

Wenn also diese Schranke fällt, dann ist auch der Interface Helper interessant. Bis dahin müsste man sich je nach Fall immer zwischen Interface Helper oder eben doch Record entscheiden. Dann doch lieber immer auf die gleiche Weise

[Stevie]

Zitat von Sir Rufo:

Unter Delphi ist das mit den Interface Helpern doch uninteressant, denn die Interfaces unterstützen keine Generics

Genau, weil b nicht geht, lassen wir a auch gleich lieber sein.
Dass es keine generischen Methoden auf Interface selber gibt, hat einen technischen Grund, nämlich den gleichen, warum es keine virtuellen Methoden mit generischen Parametern gibt: ich hab nur einen Slot in der VMT dafür, für welches T soll ich den nehmen?

Methoden in einem Interface Helper wären aber nicht virtuell.
Viel schlimmer: man kann aktuell keine helper für generische Typen bauen!

Zitat von Sir Rufo:

Mit einem record drumherum ist das dann wieder kein Problem (ist ja in Spring4D auch so vorhanden )

Wenn der Compiler da nicht bei so nem record mit ner Menge Methoden ohne das IDEFixPack, wo Andreas nen Fix für den Compiler eingebaut hat, total abröcheln würde, dann würd ich das mehr benutzen.

[himitsu]

Einen Implicit-Cast mit einem Record hatte ich zwar schon überlegt, aber die Lösung fand ich nicht gut, denn erstmal ist das für statische Methoden, auf den Interface-Typ nicht möglich
und dann kann man die Codevervollständigung auch gleich komplett vergessen.

[Dejan Vu]

Wenn also Foo IFoo implementiert und ich dann IFoo nachträglich über einen Helper erweitere, z.B. mit der Methode Bar()... Was ist dann mit Foo? Implementiert Foo dann noch IFoo?
In meiner DLL:

Delphi-Quellcode:

type
  IFoo = Interface
     procedure FooMethod;
  end;

  Foo  = Class (IFoo)
    public procedure FooMethod;
  end

Foo implementiert also IFoo. Gut.

Nun erweitere ich IFoo mit einem Helper

Delphi-Quellcode:

  IFooHelper = interface helper for IFoo
    procedure Bar;
  end;
...
var Foo : IFoo;
...
Foo.Bar; // das geht also.

Var oldFoo : Foo;

begin
  Foo.Bar // und das?

Preisfrage: Wo ist 'Bar' denn implementiert? Im Interface sicherlich nicht...

[Stevie]

Zitat von Dejan Vu:

Preisfrage: Wo ist 'Bar' denn implementiert? Im Interface sicherlich nicht...

Delphi-Quellcode:

IFooHelper = interface helper for IFoo
  procedure Bar;
end;

ist equivalent zu:

procedure Bar(const Self: IFoo); Damit kannste dir die Frage selbst beantworten.

[himitsu]

Die Funktion ist eben nicht im Interface, genauso wenig, wie bei den anderen Record/Class-Helpern oder so wie eine class procedure nicht im Objekt steckt, zu Welchem sie deklariert wurde.

Helper sollen nicht das Objekt/Interface selbst verändern, sondern nur darauf aufbauend eine Funktionen hinzufügen. (drum darf/kann man dort auch keine Felder deklarieren oder dynamic/virtual/abstract verwenden, weil das eine Veränderung erfordern würde)

[TiGü]

Zitat von Stevie:

Zitat von Dejan Vu:

Preisfrage: Wo ist 'Bar' denn implementiert? Im Interface sicherlich nicht...

Delphi-Quellcode:

IFooHelper = interface helper for IFoo
  procedure Bar;
end;

ist equivalent zu:

procedure Bar(const Self: IFoo);

Aber muss das Objekt dann nicht trotzdem IFooHelper kennen?
Wie soll das sonst funktionieren?