AW: Was nervt euch so, wärend der Programmierung.
Ich bin mir nicht sicher, ob die Intention des Threadstarters sich auf sprachliche Unzulänglichkeiten bezog oder ob er so, die Umstände am Arbeitsplatz meinte.
|
AW: Was nervt euch so, wärend der Programmierung.
Zitat:
Delphi-Quellcode:
Wenn ich das jetzt richtig verstanden habe, kann man jetzt nicht feststellen, ob TTruck<TStandardPacket> ein TCar ist um dann honk aufzurufen (Könnte ja auch ein Fußgänger ohne Hupe sein) :gruebel:
type
TCar = class(TRoadUser) public procedure honk; end; type TTruck<T: TCargo> = class(TCar) public procedure store(cargo: T); function load: T; end; |
AW: Was nervt euch so, wärend der Programmierung.
Das wird etwas speziell für diesen Thread, aber mal kurz:
TTruck ist keine Ableitung von TCar sondern direkt eine Ableitung von TObject. Man kann den daher Track z.B. nicht an eine Methode übergeben, die ein Car verlangt. Hier gab es mal etwas dazu (mein Beispiel in #13). Man kann also bestehende Klassen nicht generisch erweitern, sondern "nur" neue generische Klassen erzeugen (mit meinen Worten). |
AW: Was nervt euch so, wärend der Programmierung.
Zitat:
|
AW: Was nervt euch so, wärend der Programmierung.
[edit]
jupp [/edit] Nja wenn, dann könnte man von Klassen ableiten, dieser erweitern und bliebe dennoch kompatibel zur Vorgängerklasse > Vererbung. In meinem Fall wollte ich gerne mehrere Klassen nachträglich erweitern. > wie z.B. TEdit, TMemo und Co. Überschreiben wollte ich aber nur funktionen, welche schon in TWinControl vorhanden und somit überll gleich sind, on der Signatur her. Nun muß ich aber jede Klasse einzeln erweitern, wo es einmal auch gereicht hätte.
Delphi-Quellcode:
Sowas geht ja eben auch nicht, da TMyGen<> kein Nachfahre von TEdit ist, obwohl man das glauben könnte.
type
TMyGen<T: TCustomEdit> = class(T) protected function GetText: String; override; end; TMyEdit = TMyGen<TEdit>; TMyMemo = TMyGen<TMemo>;
Delphi-Quellcode:
Aber dafür bräuchte man eben einen Compiler, welcher nicht nur einmal durch den Code rauscht, also "weit" vorausschauend arbeiten kann,
type
TMyGen<T> = class(TEdit) end; bzw. welcher die Generics nicht gleich versucht in Code umzusetzen, sondern ihn eher als Macro interpretiert und dann später erst fertig compiliert, also bei dessen Nutzung. Makros im Allgemeinen wären ja auch noch sooooo schlecht. @Luckie: Zitat:
|
AW: Was nervt euch so, wärend der Programmierung.
@BUG und stahli:
Doch, in dem Fall ist TTruck<TStandardPacket> von TCar abgeleitet und man kann auch ganz normal auf alle TCar Methoden/Properties zugreifen. TList<T> ist nur deshalb kein Nachfahre von TList, weils einfach nicht davon abgeleitet ist, sondern von TEnumerable<T> (und das von TObject) In Delphi geht es nunmal nicht so einfach, dass man einen generischen Typen von einem nicht generischen Typen ableitet, da Delphi nunmal keinen root type hat. Man kann es nachbilden bis zu einem gewissen Grad, aber was machst du, wenn du ne TList<IMyInterface> hast und das als TList übergibst, wo jedes Element nur nen Pointer ist? Was ist mit der Referenzzählung? Was passiert bei anderen Datentypen... etc @Himitsu: Das nennt man Covarianz (die in Delphi fehlt) und ich glaube, das hab ich auch im "Wünsch dir was" Thread aufgeführt Was du vor hast, klingt nett, hat aber nix mit Generics zu tun, wie sie allgemein funktionieren. Ein Typenparameter steuert niemals die Vererbungshierarchie. TFoo<TButton> wäre covariant zu TFoo<TWinControl> (du kannst in diesem Fall ohne Probleme nen hardcast machen und alles funktioniert weiterhin) Wäre die Definition aber TFoo<T> = class(T) dann wäre der Vorgänger von TFoo<TButton> nämlich TButton von TFoo<TWinControl> wäre es TWinControl, womit die beiden generischen Typen nicht mehr covariant wären. Was du willst, sind Extensions wie es sie in .Net gibt. Zitat:
Zu dem anderen Beispiel, warum nicht das?
Delphi-Quellcode:
Um das Thema zu vertiefen, würd ich dazu raten, einen seperaten Thread zu eröffnen.
type
TMyGen<T: TCustomEdit> = class(TCustomEdit) protected function GetText: String; override; end; @Luckie: Mich nervt es, wen manche Entwickler immer direkt losprogrammieren, ohne zu recherchieren, ob es diese Funktionalität in irgendeiner Funktion oder Unit schon gibt und für alles das Rad x-mal neu erfunden wird, weil man entweder zu blöd oder zu faul zum suchen ist. |
AW: Was nervt euch so, wärend der Programmierung.
Was am Meisten nervt, sind die vielen und sehr aussagekräftigen Fehlermeldungen, wo man wenigstens noch einen Hinweis bekommt, was man wo beheben könnte.
Zitat:
|
AW: Was nervt euch so, wärend der Programmierung.
Was mich nervt, ist der Installer, der jedes mal erscheint, wenn ich das erste mal nach einem Neustart kompilieren möchte. Habe das jetzt schon seit Jahren. Zwischendrin war es ein paar mal verschwunden (ob meine vergeblichen Reparaturversuche und Neuinstallationen etwas damit zu tun hatten weiß ich nicht), aber nach einer gewissen Zeit kam es immer wieder. Inzwischen habe ich es aufgegeben.
|
AW: Was nervt euch so, wärend der Programmierung.
Zitat:
Gibt's da keine Möglichkeit das zu unterbinden? Gruß K-H |
AW: Was nervt euch so, wärend der Programmierung.
So etwas hatte ich nie. Habt Ihr irgendwelche Ordner verbogen oder so?
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:00 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