Was nervt euch so, während der Programmierung oder so allgemein

[himitsu]

Daß die Generics unbedingt die Vererbungslinie schrotten müssen, bzw. daß die gernerischen Basisklassen mit den "Alten" nichts gemeinsam haben
TList<> ist kein Nachfahre von TList.

Die könnten ja sonst auch zu praktisch sein und ich hätt' sie jetzt für was ganz Nettes nutzen können, aber so.....

und sowas geht och nich

Delphi-Quellcode:

type
  TMyGen<T: class> = class(T)
  end;

[stahli]

Das stimmt und könnte auch in den Wünsche+Träume-Thread aufgenommen werden (wenn das dort bei den Verantwortlichen gehört wird ).

[Luckie]

Mich nervt es, wen ich erst gar nicht programmieren darf, sondern es heißt: "Guck mal, ob das und das mit der und der Technologie möglich ist" und man dann nur am Recherchieren ist.

[jaenicke]

Zitat von himitsu:

Daß die Generics unbedingt die Vererbungslinie schrotten müssen, bzw. daß die gernerischen Basisklassen mit den "Alten" nichts gemeinsam haben

Naja, wie sollte man das auch umsetzen?

Zitat von himitsu:

und sowas geht och nich

Delphi-Quellcode:

type
  TMyGen<T: class> = class(T)
  end;

Hmm, sieht für mich erst einmal wenig sinnvoll aus. Wofür braucht man das?

Was mich allerdings wirklich nervt (insbesondere bei einigen generischen Klassen) ist, dass sehr viele Methoden nicht virtuell sind, die für eine Erweiterung einer Klasse essentiell wären... Auf diese Weise muss man viel Code neu schreiben, obwohl es sonst einfach nur 3 Zeilen als Erweiterung einer Klasse wären...

[Luckie]

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.

[BUG]

Zitat von jaenicke:

Zitat von himitsu:

Daß die Generics unbedingt die Vererbungslinie schrotten müssen, bzw. daß die gernerischen Basisklassen mit den "Alten" nichts gemeinsam haben

[...]
Hmm, sieht für mich erst einmal wenig sinnvoll aus. Wofür braucht man das?

Delphi-Quellcode:

type
  TCar = class(TRoadUser)
  public
    procedure honk;
  end;

type
  TTruck<T: TCargo> = class(TCar)
  public
    procedure store(cargo: T);
    function load: T;
  end;

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)

[stahli]

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).

[BUG]

Zitat von stahli:

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.

Ich vermute ja, dass es das ist, was himitsu bemängelt.

[himitsu]

[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:

type
  TMyGen<T: TCustomEdit> = class(T)
  protected
    function GetText: String; override;
  end; 

  TMyEdit = TMyGen<TEdit>;
  TMyMemo = TMyGen<TMemo>;

Sowas geht ja eben auch nicht, da TMyGen<> kein Nachfahre von TEdit ist, obwohl man das glauben könnte.

Delphi-Quellcode:

type
  TMyGen<T> = class(TEdit)
  end;

Aber dafür bräuchte man eben einen Compiler, welcher nicht nur einmal durch den Code rauscht, also "weit" vorausschauend arbeiten kann,
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:

egal ob es mit der/einer Programmiersprache zu tun hat oder nur allgemein mit dem Programmieren oder etwas damit Zusammenhängendem zu tun hat.

[Stevie]

@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 von himitsu:

Sowas geht ja eben auch nicht, da TMyGen<> kein Nachfahre von TEdit ist, obwohl man das glauben könnte.

Delphi-Quellcode:

type
  TMyGen<T> = class(TEdit)
  end;

Stimmt nicht, obiger Code ist völlig in Ordnung.
Zu dem anderen Beispiel, warum nicht das?

Delphi-Quellcode:

type
  TMyGen<T: TCustomEdit> = class(TCustomEdit)
   protected
     function GetText: String; override;
   end;

Um das Thema zu vertiefen, würd ich dazu raten, einen seperaten Thread zu eröffnen.

@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.