AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Fehlende Mehrfachvererbung bei Schnittstellen
Thema durchsuchen
Ansicht
Themen-Optionen

Fehlende Mehrfachvererbung bei Schnittstellen

Ein Thema von Der schöne Günther · begonnen am 17. Jul 2014 · letzter Beitrag vom 18. Jul 2014
Antwort Antwort
Seite 3 von 3     123   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.140 Beiträge
 
Delphi 12 Athens
 
#21

AW: Fehlende Mehrfachvererbung bei Schnittstellen

  Alt 18. Jul 2014, 20:28
[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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (18. Jul 2014 um 20:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.008 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#22

AW: Fehlende Mehrfachvererbung bei Schnittstellen

  Alt 18. Jul 2014, 20:37
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
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (18. Jul 2014 um 20:39 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.009 Beiträge
 
Delphi 12 Athens
 
#23

AW: Fehlende Mehrfachvererbung bei Schnittstellen

  Alt 18. Jul 2014, 20:42
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.008 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#24

AW: Fehlende Mehrfachvererbung bei Schnittstellen

  Alt 18. Jul 2014, 21:31
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 3     123   

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:28 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz