verschiedene class helper für eine Klasse

[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 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 von Uwe Raabe:

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 von DeddyH:

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

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 von Redeemer:

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

Warum denn nicht? Zum Beispiel: Dataset Enumerator Reloaded

[Stevie]

Zitat von jaenicke:

Zitat von TurboMagic:

Zitat von 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)

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.