verschiedene class helper für eine Klasse

[bernhard_LA]

kann ich nur eine class helper Klasse für eine Basis Klasse erstellen ? meinen Code mag der Compiler irgendwie nicht ....

Delphi-Quellcode:

type 
TStringClassHelper = class helper for TStrings
  private
  
  public

  end;



type 
TStringClassHelperZusatz = class helper for TStrings
  private
  
  public

   end;

[Uwe Raabe]

Ja, es kann immer nur einen Class Helper für je Klasse im aktuellen Scope geben.

Aber: Class Helper von Klassen sind vererbbar:

Delphi-Quellcode:

type
  TStringClassHelper = class helper for TStrings
  end;

type
  TStringClassHelperZusatz = class helper(TStringClassHelper) for TStrings
  end;

Eine andere Alternative, wenn es denn machbar ist, wären noch Class Helper für unterschiedliche Klassen:

Delphi-Quellcode:

type
  TStringClassHelper = class helper for TStrings
  end;

type
  TStringListClassHelper = class helper for TStringList
  end;

Eine TStringList kennt dann die Methoden aus beiden Helpern.

[himitsu]

Genau, es geht blöder Weise immer nur Einer, je Typ. (ich glaub nicht, dass Emba das jemals gefixt bekommt, wenn die es nichtmal schaffen von DebugDCUs den Haken wieder zu entfernen)

[edit] Auch Helper am Vorfahren haben manchmal Probleme, aber normal geht es.

Aber Class Helper kann man vererben.

Delphi-Quellcode:

TMyHelper = class helper (TAndererHelper) for TIrgendwas

, also

Delphi-Quellcode:

classHelper(x)

wie beim

Delphi-Quellcode:

class(x)

Nur bei RecordHelpern ist man angearscht, z.B. wenn man eigene Helper an string hängen will.

Ebenso kann man für abgeleitete Typen keine Helper mehrfach anhängen (wiederverwenden).
z.B. TCaption (.Caption an Forms, Labels, Buttons usw.) fehlen alle Helper vom String.

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1501981)

Eine andere Alternative, wenn es denn machbar ist, wären noch Class Helper für unterschiedliche Klassen:

Delphi-Quellcode:

type
  TStringClassHelper = class helper for TStrings
  end;

type
  TStringListClassHelper = class helper for TStringList
  end;

Eine TStringList kennt dann die Methoden aus beiden Helpern.

Da wäre ich nie drauf gekommen. Wieder was gelernt 👍

[hes]

Zitat:

Zitat von Uwe Raabe (Beitrag 1501981)

Ja, es kann immer nur einen Class Helper für je Klasse im aktuellen Scope geben.

Aber: Class Helper von Klassen sind vererbbar:

Delphi-Quellcode:

type
  TStringClassHelper = class helper for TStrings
  end;

type
  TStringClassHelperZusatz = class helper(TStringClassHelper) for TStrings
  end;

Ich habe das mal getestet. Kann es sein bei der Codevervollständigung zeigt es nur die Funktion(en) der vererbten Klasse TStringClassHelperZusatz an?
Das aus TStringClassHelper sehe ich nicht, es lässt sich aber ohne Fehler übersetzen und funktioniert.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1501982)

Genau, es geht blöder Weise immer nur Einer, je Typ. (ich glaub nicht, dass Emba das jemals gefixt bekommt, wenn die es nichtmal schaffen von DebugDCUs den Haken wieder zu entfernen)

Ich hoffe, dass EMBA es dieses Jahr schafft, dich auch mal positiv zu überraschen! ;-)

[jaenicke]

Zitat:

Zitat von TurboMagic (Beitrag 1544693)

Zitat:

Zitat von himitsu (Beitrag 1501982)

Genau, es geht blöder Weise immer nur Einer, je Typ. (ich glaub nicht, dass Emba das jemals gefixt bekommt, wenn die es nichtmal schaffen von DebugDCUs den Haken wieder zu entfernen)

Ich hoffe, dass EMBA es dieses Jahr schafft, dich auch mal positiv zu überraschen! ;-)

Das ist aber rein logisch nicht so einfach. Was ist denn, wenn es eine Methode in mehr als einem Helper gibt? Mehrfachvererbung gibt es ja in Delphi ebenfalls nicht.

In dem Fall sehe ich da keinen Bug, sondern eine logisch begründete technische Einschränkung.

[Redeemer]

Dann gilt die Reihenfolge der uses wie überall sonst auch, z.B. bei Klassen (ja, ich meine dich, TBitmap!) oder "globalen Methoden". Da allerdings der Class Helper keinen nach außen sichtbaren Namen hat, kann man dann leider nicht die Auswahl überschreiben, indem man die Unit angibt.

[TurboMagic]

Zitat:

Zitat von jaenicke (Beitrag 1544696)

Zitat:

Zitat von TurboMagic (Beitrag 1544693)

Zitat:

Zitat von himitsu (Beitrag 1501982)

Genau, es geht blöder Weise immer nur Einer, je Typ. (ich glaub nicht, dass Emba das jemals gefixt bekommt, wenn die es nichtmal schaffen von DebugDCUs den Haken wieder zu entfernen)

Ich hoffe, dass EMBA es dieses Jahr schafft, dich auch mal positiv zu überraschen! ;-)

Das ist aber rein logisch nicht so einfach. Was ist denn, wenn es eine Methode in mehr als einem Helper gibt? Mehrfachvererbung gibt es ja in Delphi ebenfalls nicht.

In dem Fall sehe ich da keinen Bug, sondern eine logisch begründete technische Einschränkung.

Da verstehe ich dich natürlich! Nur: es könnte ja auch noch ganz andere Sachen 2025 geben, über die mach einer sich freuen würde ;-)
Das würde uns jetzt aber auf ein anderes Gleis, weg vom eigentlichen Thema, bringen.
Ich wollte nur den Negativismus gleich am jahresanfang etwas dämpfen ;-)

[himitsu]

Zitat:

Zitat von Redeemer (Beitrag 1544698)

Dann gilt die Reihenfolge der uses wie überall sonst auch, z.B. bei Klassen (ja, ich meine dich, TBitmap!) oder "globalen Methoden". Da allerdings der Class Helper keinen nach außen sichtbaren Namen hat, kann man dann leider nicht die Auswahl überschreiben, indem man die Unit angibt.

Wo soll es da ein Problem geben?
Genauso, wie Overload, bzw. Ohne.

Der Helper, welcher zuletzt im Scope liegt, dessen Methode/Property hat Vorrang. (je nach Signatur)