Fehlende Mehrfachvererbung bei Schnittstellen

[Blup]

Danke, du hast den Problemkreis sehr anschaulich beschrieben.
Der Delphicompiler müsste nur zwei Dinge zusätzliche beherschen:

Delphi-Quellcode:

TFoo = class(TInterfacedObject, IFoo) // IBar, IBaz, alle Eltern durch den Compiler versteckt mit angelegt} 

DoSomething(foo); // (foo as IBar) duch den Compiler automatische Abfrage des passenden Elter

Das vermisse ich eigentlich schon fast so lange, wie ich mit Interfaces in Delphi arbeite.

[Sir Rufo]

Zitat von Blup:

Danke, du hast den Problemkreis sehr anschaulich beschrieben.
Der Delphicompiler müsste nur zwei Dinge zusätzliche beherschen:

Delphi-Quellcode:

TFoo = class(TInterfacedObject, IFoo) // IBar, IBaz, alle Eltern durch den Compiler versteckt mit angelegt} 

DoSomething(foo); // (foo as IBar) duch den Compiler automatische Abfrage des passenden Elter

Das vermisse ich eigentlich schon fast so lange, wie ich mit Interfaces in Delphi arbeite.

Es geht ja mit Delphi schon so:

Delphi-Quellcode:

procedure DoSomethingWithBar( ABar : IBar );
procedure DoSomethingWithBaz( ABaz : IBaz );

TFoo = class( TInterfacedObject, IBar, IBaz, IFoo )
...
end;

var
  Foo : TFoo;
begin
  Foo := TFoo.Create;
  DoSomethingWithBar( Foo );
  DoSomethingWithBaz( Foo );
end;

Das Hauptproblem ist aber hierbei, dass nach dem Aufruf von DoSomethingWithBar( Foo ); die Foo-Instanz sich in Rauch auflöst. Somit müsste man entweder TFoo von TPersistentInterface ableiten und explizit freigeben

Delphi-Quellcode:

TFoo = class( TInterfacedPersistent, IBar, IBaz, IFoo )
end;

var
  Foo : TFoo;
begin
  Foo := TFoo.Create;
  try
    DoSomethingWithBar( Foo );
    DoSomethingWithBaz( Foo );
  finally
    Foo.Free;
  end;
end;

oder sich eben zusätzlich eine IFoo Referenz merken.

Delphi-Quellcode:

var
  Foo : TFoo;
  FooIntf : IFoo;
begin
  Foo := TFoo.Create;
  FooIntf := Foo;
  DoSomethingWithBar( Foo );
  DoSomethingWithBaz( Foo );
end;

oder man hat ARC und dann klappt es einfach so ohne dieses Gedöns.

[Stevie]

Zitat von Sir Rufo:

Es geht ja mit Delphi schon so:
*snip*

Das hast du dir aber nur so hingebogen, weil foo von TFoo ist und nicht wie im Beispiel oben von IFoo , worum es auch hier eigentlich geht.

Ich kann dir nicht sagen, was C# da genau macht, wenn man ein IFoo an ein IBar oder IBaz übergibt (hab mir den IL Code nicht angeschaut). Aber dadurch, dass dort fest steht, "wenn IFoo implementiert wird, dann ist auch IBar und IBaz implementiert" ist sichergestellt, dass ein Cast von IFoo auf IBar oder IBaz immer erfolgreich ist.

Und genau das geht in Delphi ebend nicht.

Zitat von Blup:

Der Delphicompiler müsste nur zwei Dinge zusätzliche beherschen:

Delphi-Quellcode:

TFoo = class(TInterfacedObject, IFoo) // IBar, IBaz, alle Eltern durch den Compiler versteckt mit angelegt} 

DoSomething(foo); // (foo as IBar) duch den Compiler automatische Abfrage des passenden Elter

Das vermisse ich eigentlich schon fast so lange, wie ich mit Interfaces in Delphi arbeite.

Exakt. Ich werd mal nachfragen, ob sowas mal angegangen werden könnte.

[himitsu]

Zitat von Blup:

[delphi]
TFoo = class(TInterfacedObject, IFoo) // IBar, IBaz, alle Eltern durch den Compiler versteckt mit angelegt}

Nö.

Denn was ist, wenn jemand nicht will, daß das Objekt auch alle Vorfahren der supporteten Interfaces supported?


Delphi hat nunmal eine strenge Typsicherheit und sowas würde das total aufweichen,
was dann schnell mal Probleme mit überladenen Methoden ergibt, da am Ende dann jede Interface-Variable wie IInterface aussieht.

[Stevie]

Zitat von himitsu:

Denn was ist, wenn jemand nicht will, daß das Objekt auch alle Vorfahren der supporteten Interfaces supported?

Dann leite deine Interfaces halt nicht voneinander ab, so dass der Compiler die nicht dort einfügt?

Die ganzen Devs, die mit C# programmieren, müssen ja echt arme Schweine sein, da sie mit solchen grausamen Problem zu kämpfen haben ... /ironie off

[Uwe Raabe]

Zitat von Stevie:

Zitat von himitsu:

Denn was ist, wenn jemand nicht will, daß das Objekt auch alle Vorfahren der supporteten Interfaces supported?

Dann leite deine Interfaces halt nicht voneinander ab, so dass der Compiler die nicht dort einfügt?

Dann ist der Wunsch nach automatischem Einbinden der Parent-Interfaces ebenfalls obsolet.

Hier beißen sich einfach zwei Anwenderwünsche. Die aktuelle Implementation bietet aber einen Möglichkeit, das gewünschte trotzdem zu erreichen (durch explizites Aufführen der Interfaces), während ein implizites Einbinden der Parent-Interfaces nicht so einfach verhindert werden kann. Ergo: der aktuelle Ansatz ist flexibler.

[Stevie]

Zitat von Uwe Raabe:

Hier beißen sich einfach zwei Anwenderwünsche. Die aktuelle Implementation bietet aber einen Möglichkeit, das gewünschte trotzdem zu erreichen (durch explizites Aufführen der Interfaces), während ein implizites Einbinden der Parent-Interfaces nicht so einfach verhindert werden kann. Ergo: der aktuelle Ansatz ist flexibler.

Der Wunsch, dass ein Elterninterface nicht explizit aufgenommen wird, ist imho rein theoretisch, denn man muss ja die "geerbten" Methoden sowieso implementieren. Und angenommen, IFoo "erbt" von IBar, kann ich ein IFoo derzeit immernoch einem IBar zuweisen. Aber wenn ich ein IFoo frage, "hey Supports(foo, IBar)" sagt es NÖ! Wie unlogisch ist das denn bitte?

Die aktuelle Implementierung ist designtechnisch komplett Tinnef und nur so weil Microsoft irgendwann mal Scheiße gebaut hat mit ihrer COM Implementierung. Er ist nicht flexibler sondern einfach unsafe.