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)

[Redeemer]

Das Problem ist, dass du die Auswahl des Compilers nicht überschreiben kannst, falls jeweils ein Class Helper für dieselbe Klasse in zwei Units dieselbe Methodensignatur hat.

Delphi-Quellcode:

unit Unit1;

type
TWuppdiHelper1 = class helper for TWuppdi
  procedure DoWuppdi();
end

Delphi-Quellcode:

unit Unit2;

type
TWuppdiHelper2 = class helper for TWuppdi
  procedure DoWuppdi();
end

In einer Unit, die beide Units einbindet, kann man dann doch nur eines der

Delphi-Quellcode:

DoWuppdi()

aufrufen.

[DeddyH]

Dann wird eben der genommen, der zuletzt eingebunden wurde. Das geht mit regulären Prozeduren ja auch.

[Uwe Raabe]

Worauf Janni hinaus will ist wohl, dass man bei Helpern nicht einfach den Unit-Namen voranstellen kann, um den Default zu überschreiben.

[DeddyH]

Ja gut, dann ist das eben so. Aber der Ist-Zustand ist ja auch nicht das Gelbe vom Ei.

[Redeemer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1545184)

Worauf Janni hinaus will ist wohl, dass man bei Helpern nicht einfach den Unit-Namen voranstellen kann, um den Default zu überschreiben.

Richtig. Und ich vermute, dass das der Grund ist, warum sie zwei Class Helper im Scope nicht zulassen.
Allerdings dürfte es keinen plausiblen Grund geben, für dieselbe Klasse zwei Helper-Methoden mit derselben Methodensignatur zu schreiben, die unterschiedliche Dinge tun. Also dürfte das von mir beschriebene Problem gegenüber der Einschränkung auf nur 1 Class Helper im Scope das geringe Übel sein.

[DeddyH]

Manchmal bekommt man ja auch den Eindruck, dass mit viel Getöse neue supertolle Features für die nächste Delphi-Version angekündigt werden, die sich dann, wenn man sie etwas intensiver als in den mitgelieferten Demos benutzen möchte, als Papiertiger erweisen.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1545189)

Ja gut, dann ist das eben so. Aber der Ist-Zustand ist ja auch nicht das Gelbe vom Ei.

In der Tat! Man vermeidet damit zwar ein Teilproblem einer Multi-Helper Implementierung, verhindert aber die übrigen Möglichkeiten, die mit so einem Feature daherkommen.

Das Problem trifft ja auch nur bei Helpern zu, die man nicht selbst unter Kontrolle hat, sonst könnte man ja die Namen anpassen.
Aber da dann ja beliebig viele Helper erlaubt sind, gäbe es doch einen Workaround:

Delphi-Quellcode:

unit Unit1Wrapper;

interface

type
  TWuppdiHelper1Wrapper = class helper for TWuppdi
    procedure DoWuppdi1();
  end;

implementation

uses
  Unit1;

procedure TWuppdiHelper1Wrapper.DoWuppdi1;
begin
  DoWuppdi;
end;

Delphi-Quellcode:

unit Unit2Wrapper;

interface

type
  TWuppdiHelper2Wrapper = class helper for TWuppdi
    procedure DoWuppdi2();
  end;

implementation

uses
  Unit2;

procedure TWuppdiHelper2Wrapper.DoWuppdi2;
begin
  DoWuppdi;
end;

Die Wrapper-Units müssen dann ja auch nur die Namenskollisionen auflösen, der Rest kann ja so verwendet werden.

Übrigens kann ma mehrere Helper für eine Klasse schon jetzt realisieren, wenn man die Helper ableitet (muss man halt auch den Source haben und funktioniert leider nicht bei record helper):

Delphi-Quellcode:

type
  TWuppdiHelper1 = class helper for TWuppdi
    procedure DoWuppdi1;
  end;

type
  TWuppdiHelper2 = class helper(TWuppdiHelper1) for TWuppdi
    procedure DoWuppdi2;
  end;

...

  var wuppdi := TWuppdi.Create;
  try
    wuppdi.DoWuppdi1; // Code Completion sieht das zwar nicht, aber der Compiler schon.
    wuppdi.DoWuppdi2;
  finally
    wuppdi.Free;
  end;

Zitat:

Zitat von DeddyH (Beitrag 1545195)

Manchmal bekommt man ja auch den Eindruck, dass mit viel Getöse neue supertolle Features für die nächste Delphi-Version angekündigt werden, die sich dann, wenn man sie etwas intensiver als in den mitgelieferten Demos benutzen möchte, als Papiertiger erweisen.

Mein Nutzungsgrad von Helpern ist allerdings so hoch, dass man da mitnichten von Papiertigern sprechen kann.

[Redeemer]

Ergibt es eigentlich Sinn, seine Helper mit anderen Entwicklern zu teilen?

[Uwe Raabe]

Zitat:

Zitat von Redeemer (Beitrag 1545197)

Ergibt es eigentlich Sinn, seine Helper mit anderen Entwicklern zu teilen?

Warum denn nicht? Zum Beispiel: Dataset Enumerator Reloaded

[Stevie]

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.

Ausreden. Es gibt sowas, das nennt sich "overload resolution". Wenn es identisch benamte Methoden in verschiedenen Helpern gäbe, dann müssten diese wie Überladungen behandelt werden, ist schon ewig so bei den Extension methods in C#.
Aber bei Borland und später Embarcadero haben sie sich damals auf ihrem ach so tollen Patent für die helper ausgeruht (was ursprünglich auch eigtl nur ein Hack war) und es nicht weiter entwickelt, während andere Sprachen diesbezüglich an ihnen vorbei gezogen sind.